PBKDF2 Key Derivation
Reproduce password-based key bytes locally with explicit salt, hash, iteration, and output-length settings.
PBKDF2 applies an HMAC-based pseudorandom function repeatedly to a password and salt. The password, salt bytes, hash, iteration count, and requested output length all affect the final derived bytes.
- Copy the exact password text and confirm how that system encodes it.
- Paste the salt and select whether it is text, hex, Base64, or Base64URL.
- Match the HMAC hash, iteration count, and output length.
- Derive the bytes, then compare the output in the encoding used by the other application.
Load the sample to derive 32 bytes from password password, UTF-8 salt salt, one iteration, and HMAC-SHA-256. The expected hex output is:
120fb6cffcf8b32c43e7225256c4f837a86548c92ccc35480805987cb70be17b
This deliberately weak configuration is a deterministic interoperability check, not a configuration for real secrets.
This page allows up to 1,000,000 iterations and 128 output bytes, with a second cap of 2,000,000 iteration-by-output-block work units. The cap is a page performance boundary, not a recommendation for your security policy. Match your system's documented settings.
- RFC 8018 defines PBKDF2 and its password, salt, iteration, and derived-key inputs.
- MDN SubtleCrypto deriveBits documents the browser API used by this page.
Is the salt secret?
No. A salt is normally stored with the parameters needed to reproduce the derivation. It should be unique for a new password-based record or encryption package.
Why does changing one parameter change every output byte?
PBKDF2 is deterministic only when the password, salt bytes, hash, iterations, and output length all match.
Should I store application passwords as this raw output?
No. Password databases normally store a complete versioned verifier string from a dedicated password-hashing workflow, including its salt and cost parameters.