How many PBKDF2 iterations should I use?

OWASP's Password Storage Cheat Sheet gives 600,000 for HMAC-SHA256, 220,000 for HMAC-SHA512 and 1,400,000 for HMAC-SHA1, and no figure for SHA-384. The note under Iterations says whether your count meets the figure for the hash you chose. For new password storage OWASP puts Argon2id first and scrypt second, and recommends PBKDF2 where FIPS-140 validated algorithms are required.

How long should a PBKDF2 salt be?

NIST SP 800-132 says the randomly generated part of the salt shall be at least 128 bits, which is 16 bytes. The Random 16-byte salt button switches the salt format to Hex and fills in a new random salt; a shorter salt still works but gets a note.

What do the RFC 6070 test vectors give?

The password password and the salt salt with HMAC-SHA1 and 160 bits give 0c60c80f961f0e71f3a9b524af6012062fe037a6 after 1 iteration and 4b007901b765489abead49d926f721d065a429c1 after 4,096. Load RFC 6070 test vector fills in the 4,096-iteration case, so you can check the page against the RFC. In Base64 the 4,096-iteration key is SwB5AbdlSJq+rUnZJvch0GWkKcE=.

Is a PBKDF2 key the same as a stored password hash?

Not as this page shows it. The output is the raw derived key in hex or Base64. A stored password record also keeps the hash, iteration count and salt next to the key, in whatever format your framework uses.

Should the salt be text, hex or Base64?

Whichever matches how your code holds the salt bytes; the key depends only on the bytes. Text is read as UTF-8, so the text salt is the hex 73616c74 and the Base64 c2FsdA==, and all three give the same key. The text 00 is two bytes, while the hex 00 is one, so those give different keys.

What key length should I pick for PBKDF2?

Usually the hash output size: 160 bits for SHA-1, 256 for SHA-256, 384 for SHA-384, 512 for SHA-512. A longer key is built from more blocks, and each block runs the full iteration count again (RFC 8018), so 512 bits from SHA-256 takes twice the work. The first 256 bits of it are the 256-bit key: with password, salt and 4,096 iterations, both start c5e478d5…aa98134a.

PBKDF2 Calculator

Derive a PBKDF2 key in hex or Base64 from a password and salt with HMAC-SHA-1, SHA-256, SHA-384 or SHA-512, and check it against a key you paste. How it works

Password

Enter a password to derive a key.

Salt

4 bytes. NIST SP 800-132 asks for a random salt of at least 16 bytes.

Salt format

Iterations

Meets the OWASP figure of 600,000 for PBKDF2-HMAC-SHA-256.

Key Length (bits)

A multiple of 8, from 8 to 4,096 bits.

Hash Algorithm

Derived key

Press Derive Key

Output format

Derived Key (Hex)

Expected key (Hex, optional)

Paste a key to check the derived key against it. It is not saved.

About the PBKDF2 Calculator

The password password with the salt salt, 600,000 iterations of HMAC-SHA-256 and a 256-bit key gives the PBKDF2 key 669cfe52…005178 in hex. This PBKDF2 calculator derives that key from any password, salt, iteration count, key length and hash with the browser's Web Crypto API, and starts at those settings. For the count, the OWASP Password Storage Cheat Sheet (checked October 2026) recommends 600,000 iterations for PBKDF2-HMAC-SHA256, 220,000 for PBKDF2-HMAC-SHA512 and 1,400,000 for PBKDF2-HMAC-SHA1, which it lists as legacy only.

RFC 6070 test vectors (PBKDF2-HMAC-SHA1)

Password	Salt	Iterations	Key length (bits)	Derived key (hex)
password	salt	1	160	0c60c80f961f0e71f3a9b524af6012062fe037a6
password	salt	2	160	ea6c014dc72d6f8ccd1ed92ace1d41f0d8de8957
password	salt	4,096	160	4b007901b765489abead49d926f721d065a429c1
passwordPASSWORDpassword	saltSALTsaltSALTsaltSALTsaltSALTsalt	4,096	200	3d2eec4fe41c849b80c8d83662c0e44a8b291a964cf2f07038

Computed by this tool, with the salt as text; the keys match the ones printed in RFC 6070. The RFC also has a vector with 16,777,216 iterations, above the tool's limit, and one whose password and salt contain a NUL character.

SHA-256 and SHA-512 with the password password and the salt salt

Hash	Iterations	Key length (bits)	Derived key (hex)
SHA-256	1	256	120fb6cffcf8b32c43e7225256c4f837a86548c92ccc35480805987cb70be17b
SHA-256	4,096	256	c5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
SHA-256	600,000	256	669cfe52482116fda1aa2cbe409b2f56c8e4563752b7a28f6eaab614ee005178
SHA-512	220,000	512	3ede6b8c2ba493194db1febc21d3be4fc1c7d63f4a6bcc14ad9ae07c63432c6a867beca4a0dc50070666875567d813cc3bfd3607e634ba6087934cb5ec4bb99a

OWASP iteration figures for PBKDF2

Hash	OWASP figure	Note under Iterations at 600,000
SHA-1	1,400,000	Below the OWASP figure of 1,400,000 for PBKDF2-HMAC-SHA-1. OWASP lists PBKDF2-HMAC-SHA1 as legacy only.
SHA-256	600,000	Meets the OWASP figure of 600,000 for PBKDF2-HMAC-SHA-256.
SHA-384	None published	OWASP publishes no iteration figure for SHA-384.
SHA-512	220,000	Meets the OWASP figure of 220,000 for PBKDF2-HMAC-SHA-512.

From the OWASP Password Storage Cheat Sheet. OWASP puts Argon2id first for new password storage and scrypt second.

Frequently asked questions

How many PBKDF2 iterations should I use?: OWASP's Password Storage Cheat Sheet gives 600,000 for HMAC-SHA256, 220,000 for HMAC-SHA512 and 1,400,000 for HMAC-SHA1, and no figure for SHA-384. The note under Iterations says whether your count meets the figure for the hash you chose. For new password storage OWASP puts Argon2id first and scrypt second, and recommends PBKDF2 where FIPS-140 validated algorithms are required.
How long should a PBKDF2 salt be?: NIST SP 800-132 says the randomly generated part of the salt shall be at least 128 bits, which is 16 bytes. The Random 16-byte salt button switches the salt format to Hex and fills in a new random salt; a shorter salt still works but gets a note.
What do the RFC 6070 test vectors give?: The password password and the salt salt with HMAC-SHA1 and 160 bits give 0c60c80f961f0e71f3a9b524af6012062fe037a6 after 1 iteration and 4b007901b765489abead49d926f721d065a429c1 after 4,096. Load RFC 6070 test vector fills in the 4,096-iteration case, so you can check the page against the RFC. In Base64 the 4,096-iteration key is SwB5AbdlSJq+rUnZJvch0GWkKcE=.
Is a PBKDF2 key the same as a stored password hash?: Not as this page shows it. The output is the raw derived key in hex or Base64. A stored password record also keeps the hash, iteration count and salt next to the key, in whatever format your framework uses.
Should the salt be text, hex or Base64?: Whichever matches how your code holds the salt bytes; the key depends only on the bytes. Text is read as UTF-8, so the text salt is the hex 73616c74 and the Base64 c2FsdA==, and all three give the same key. The text 00 is two bytes, while the hex 00 is one, so those give different keys.
What key length should I pick for PBKDF2?: Usually the hash output size: 160 bits for SHA-1, 256 for SHA-256, 384 for SHA-384, 512 for SHA-512. A longer key is built from more blocks, and each block runs the full iteration count again (RFC 8018), so 512 bits from SHA-256 takes twice the work. The first 256 bits of it are the 256-bit key: with password, salt and 4,096 iterations, both start c5e478d5…aa98134a.

Checking a PBKDF2 setup

Developers use it to check their own PBKDF2 code: enter the same password, salt, iteration count, key length and hash, and the key must match byte for byte. Paste your key into Expected key and the page says Matches the expected key. or Does not match the expected key.; switch Output format to Base64 if your code stores keys that way. Load RFC 6070 test vector fills in a published case, so you can confirm the page itself before you trust it. When the keys differ, the usual causes are a salt read in the wrong format (text where your code uses hex bytes), a key length in bytes where the page wants bits, or a different hash. The note under Iterations says whether your count meets the OWASP figure for the chosen hash, listed in the table on this page.

The PBKDF2 function

PBKDF2 (RFC 8018) builds the key from blocks. For block i, U1 = HMAC(password, salt || i), each following U = HMAC(password, previous U), and the block is U1 xor U2 xor … xor Uc for c iterations; blocks are joined and cut to the key length. The password is encoded as UTF-8, the salt is read as UTF-8 text, hex or Base64, and the browser's Web Crypto API does the hashing. Example from RFC 6070: password password, salt salt, 4,096 iterations, 160 bits and SHA-1 give 4b007901b765489abead49d926f721d065a429c1. The same password and salt with SHA-256, 600,000 iterations and 256 bits give 669cfe52482116fda1aa2cbe409b2f56c8e4563752b7a28f6eaab614ee005178. Limits: 1 to 10,000,000 iterations, 8 to 4,096 bits in multiples of 8, and a salt of up to 10,000 characters.

Fun Fact: One of the six RFC 6070 test vectors runs 16,777,216 iterations of HMAC-SHA1, two to the 24th power. That is above this page's limit of 10,000,000, so the page cannot reproduce that vector.

Related Tools

View all tools

Dev

Password Generator

Generate a random password of 8 to 128 characters from uppercase, lowercase, numbers and symbols, and see its entropy in bits. Can skip look-alike characters.

Dev

Hash Generator

Compute the MD5, SHA-1, SHA-256, SHA-384 or SHA-512 hash of text or a file and compare it with an expected checksum. The file is hashed in your browser.

Dev

HMAC Generator

Compute an HMAC with SHA-1, SHA-256, SHA-384 or SHA-512 and check it against a signature, with webhook presets for GitHub, Stripe, Shopify and Slack.

Dev

AES Encryption

Encrypt and decrypt text with a password using AES-256-GCM, the key derived by PBKDF2-SHA256 at 600,000 iterations. Strength depends on the password.

Dev

Text Encryptor and Decryptor

Encrypt or decrypt text with a password using AES-256-GCM and a PBKDF2-SHA-256 key of 600,000 iterations. The password cannot be recovered if lost.

Dev

UUID v7 Generator

Generate 1 to 1,000 UUID v7 values that stay in creation order on one page, and decode a UUID to its version, variant and timestamp.