HKDF Key Derivation Calculator | RFC 5869 Extract and Expand, side by side
A tool that splits HKDF (HMAC-based Key Derivation Function) into its two stages so you can see both. Feed it IKM, salt, and info, pick SHA-256/384/512, and it shows the Extract-stage PRK (pseudorandom key) next to the Expand-stage OKM (output keying material) in hex. Built for checking key schedules and reproducing test vectors.
💡 About this tool
If you've ever implemented the key schedule for TLS 1.3, the Signal Protocol, or the Noise Framework, you've hit the moment where your derived key doesn't match the spec and you can't tell why. HKDF is internally Extract -> Expand, but most libraries only expose a single HKDF(ikm, salt, info, length) call. The intermediate PRK stays hidden, so when bytes don't line up you can't tell whether Extract or Expand is the culprit.
This calculator surfaces PRK = HMAC(salt, IKM) on its own and shows the OKM derived from it right below. Leave salt empty and it follows RFC 5869 by using HashLen zero bytes as the salt. The OKM caps at 255xHashLen bytes (8160 for SHA-256); asking for more returns an error. Everything runs through the browser's native Web Crypto API (crypto.subtle) HKDF and HMAC, so the numbers match what your runtime would produce.
The IKM, salt, and info you type are raw keying material. They never leave the browser, so you can paste test keys without worrying about them being sent anywhere.
🧐 Frequently Asked Questions
Q. What's the difference between PRK and OKM? The PRK (pseudorandom key) is the Extract output: an HMAC of the IKM keyed by the salt, fixed at the hash length. The OKM (output keying material) is the Expand output: the final key of any requested length, stretched from the PRK and info. The OKM is what your application actually uses.
Q. What happens if I leave salt empty? RFC 5869 says an absent salt is treated as HashLen zero bytes. This tool does the same: clear the salt field and a zero salt is used automatically.
Q. Do I enter hex or a string?
IKM, salt, and info are treated as UTF-8 byte sequences. Type abc and you get 3 bytes (0x61 0x62 0x63). If you need specific raw bytes, you supply the text whose UTF-8 encoding equals those bytes.
Q. What's the maximum OKM length? 255xHashLen bytes: 8160 for SHA-256, 12240 for SHA-384, 16320 for SHA-512. The limit comes from Expand's single-byte counter (1 to 255).
Q. How is this different from PBKDF2 or Argon2? PBKDF2 and Argon2 are key-stretching functions that deliberately slow down password hashing. HKDF is a key-derivation function that distributes one already-high-entropy secret into several purpose-specific keys. It has no slow-by-design work factor; the goals are different.
Q. My output doesn't match another tool Differences come from how salt zero-padding is handled, whether info is present, and UTF-8 versus raw-byte interpretation. Confirm all three inputs are byte-for-byte identical.
📚 Fun Facts
HKDF was standardized in 2010 by Hugo Krawczyk and Pasi Eronen as RFC 5869. Its "Extract-then-Expand" design first squeezes messy entropy into a uniform PRK (extract), then expands that into as many keys as you need. That separation is what lets it derive safe keys from biased inputs like a raw Diffie-Hellman shared secret. TLS 1.3 builds its entire key schedule on HKDF, leaning heavily on a labeled variant called HKDF-Expand-Label. Putting a context string in the info field to fork one IKM into independent "encryption" and "authentication" keys is the canonical pattern - the whole reason the info parameter exists.