HMAC, PBKDF2 & HKDF Calculator

Compute a keyed message authentication code with HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 or HMAC-SHA-512 (RFC 2104) over text, hex bytes or whole files — keys as text, hex or Base64. Or derive keys with PBKDF2 (RFC 8018) and HKDF (RFC 5869). Every result can be rendered as hex, upper-case hex, Base64 or Base64url. For plain digests see the Hash Generator; for checksums see the CRC Calculator; for HMAC as used inside JWTs see the JWT Decoder.
Runs entirely locally — keys and messages never leave your tab. Files up to 200 MB.
Construction: Output:
HMAC algorithm: RFC 2104 — MD5 variant requires md5.js (loaded by this page).
Secret key (shared secret; any length, text below is UTF-8 encoded)
Hex reading tolerates spaces, colons and 0x prefixes; Base64 must be padded or unpadded standard form.
An empty key is legal per RFC 2104 but almost always a mistake — HMAC with no key is just a slow hash.
Message text (the data to authenticate, UTF-8 encoded)
HMAC output (one line: construction, parameters, value)
The first line records the exact parameters used (algorithm, reading, input sizes), so a copy-pasted result is always reproducible.
Which construction do you need?
HMAC turns a shared secret plus a message into an authenticator: the receiver who knows the key can recompute it and detect tampering. It is the “HS256” inside every signed JWT (see the JWT Decoder) and half of the world’s API-request signing schemes. PBKDF2 is for stretching a human password into a key: it repeats HMAC thousands of times so that each password guess costs the attacker the same delay. HKDF is for protocol keys: it takes already-random secret bytes (e.g. a DH shared secret) and safely expands them into several purpose-bound keys — TLS 1.3 derives all of its traffic keys this way. Rule of thumb: authenticate → HMAC; password → PBKDF2 (or scrypt/Argon2, see the Password Hash Generator once published); uniform secret → HKDF.
Self-test
Runs the page engines against published vectors: 10 HMAC anchors (RFC 2202/4231-style, five algorithms × two inputs), 6 PBKDF2 anchors (SHA-1 and SHA-256 at three iteration counts) and the four RFC 5869 HKDF test cases A.1–A.4. Nothing is sent anywhere.
HMAC, PBKDF2 and HKDF — keyed hashing explained from scratch
In one sentence: a bare hash like SHA-256 anyone can compute, so it proves nothing about who sent a message — HMAC mixes in a secret key so only key-holders can produce (or verify) the digest; PBKDF2 and HKDF then reuse that same HMAC machinery to turn secrets into keys, slowly for passwords and quickly for already-random material.
What HMAC is (RFC 2104)

The construction. HMAC is two hash runs, not one. Your key is padded to the hash’s block size (64 bytes for MD5/SHA-1/SHA-256, 128 for SHA-384/512); the message is hashed once with the key XOR a fixed inner pad, and that digest is hashed again with the key XOR a fixed outer pad. This double-sandwich is provably secure as long as the underlying hash is a decent pseudorandom function — which is why HMAC-MD5 still resists practical collision attacks that broke plain MD5 (though it is retired anyway, see below).

Keys. Any key length works: shorter than the block size is used as-is (but under 32 bytes is frowned upon), longer is first hashed. The same page lets you type the key as text, hex or Base64 so that a 64-hex-character production key can be pasted without someone mistaking it for a 64-character text password — the reading is recorded in the output line for exactly that reason.

Where you meet it. The HS256 field of a JWT header is literally HMAC-SHA-256 over the base64url-encoded token parts (the JWT Decoder on this site computes exactly that when you paste an HS256 secret). Webhook signatures (Stripe, GitHub), AWS SigV4, TLS record protection (older versions) and OpenSSH’s umac-64@openssh.com cousin all belong to the same family.

Why not just hash(message || key)? Length-extension: every hash in the MD5/SHA-1/SHA-2 family lets an attacker who knows H(secret || msg) compute H(secret || msg || padding || anything) without the secret. HMAC’s inner/outer split kills that class of attack. It is the single most common DIY mistake in API-signature code — and the reason HMAC exists.

What PBKDF2 is (RFC 8018)

Slow by design. A password has maybe 40 bits of real entropy; an attacker’s GPU tries billions of raw SHA-256 per second. PBKDF2 runs HMAC(password, salt) over and over — iter times — so each guess costs the same iter HMACs for you and for the attacker. The default here is 600,000 iterations with HMAC-SHA-256, the OWASP Password Storage Cheat Sheet baseline; the slider goes to ten million because security guidance ratchets upward as hardware speeds up.

Salt. A per-password random salt means identical users no longer hash identically, and precomputed tables (rainbow tables) become worthless. It is not secret — it is stored next to the hash — it only has to be unique. 16 random bytes is the norm.

Known weakness. PBKDF2 is CPU-hard but not memory-hard: GPUs and ASICs parallelize it embarrassingly well. That is why the modern advice is scrypt or Argon2id where a password hash storage is being designed (the Password Hash Generator page in this family covers them), and PBKDF2 remains the right answer for compatibility and FIPS-140 settings.

What HKDF is (RFC 5869)

Extract, then expand. HKDF does two jobs. Extract: squash possibly-uneven input key material (a Diffie–Hellman shared secret, for example) together with a salt into one short pseudorandom key PRK = HMAC(salt, IKM). Expand: stretch that PRK to any length up to 255 hash-blocks, with each output block chained to the previous and tagged by the info field. The result is that one secret can safely give you an encryption key, a MAC key and an IV, all separated.

Not for passwords. HKDF assumes its input already has full entropy — it does one HMAC per 32 output bytes, so a human password goes through it essentially instantly, exactly what an attacker wants. Feeding passwords through HKDF instead of PBKDF2 is a classic design error; the info field is for purpose labels ("client traffic key", "server iv"), not for extra entropy.

Where you meet it. TLS 1.3 derives every key it uses from the handshake secret via HKDF; WireGuard, Signal, EAP-TLS 1.3 and JSON Web Encryption (as the direct key-agreement KDF) all appear on the same family tree.

Anchor values — reproduce them on this page

The first two tables are the test vectors this page’s Sample button and self-test are built on (key "key", message “The quick brown fox jumps over the lazy dog”; then the RFC-style case of a 16-byte 0x0b key and message “Hi There”). All were generated by an independent native implementation and re-verified on this page.

HMAC of “fox”, key = keyDigest (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
KDF anchorsParametersOutput (hex, first bytes)
PBKDF2-HMAC-SHA-1password / salt, c=4096, 32 bytes4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256password / salt, c=4096, 32 bytesc5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, salt=00..0c, info=f0..f9, L=423cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, salt=60..af, info=b0..ff, L=82b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, empty salt and info, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Common mistakes
  • Confusing HMAC with encryption. HMAC proves integrity and origin (given a shared secret); it hides nothing. Anyone without the key still sees the full message.
  • Confusing HMAC with a signature. Digital signatures are public-key: one signs, anyone verifies. HMAC is symmetric: every verifier could also forge. For non-repudiation you need RSA/ECDSA (see the RSA tool in this family once published), not HMAC.
  • Key reading mismatches. A 64-character hex string pasted into a Text key box becomes 64 bytes, not 32 — and the HMAC changes completely. This page prints the reading in the output line; when two tools disagree, that is the first thing to compare.
  • PBKDF2 iter too low. 1,000 iterations was reasonable in 2000; today GPU rigs eat it. If your system still stores 1,000-iteration hashes, plan a rehash-on-login migration.
  • HKDF on a password. One HMAC per output block means a password goes through instantly — use PBKDF2 (or Argon2id) for passwords and HKDF for high-entropy secrets.
  • Reusing one derived key for everything. The fix is free: derive separate keys with different info labels. Two keys from one IKM with different labels are independent by design.
FAQ

Is HMAC-MD5 broken? As a collision-resistant hash MD5 is dead, but HMAC-MD5’s security depends on MD5 as a pseudorandom function, and no practical break is known. Retired anyway — there is no reason to pick it over HMAC-SHA-256 except compatibility with an old protocol.

How long should my HMAC key be? At least the hash’s output size (32 bytes for SHA-256) and generated by a CSPRNG. A key shorter than the digest is allowed, but every bit below it directly reduces security.

Does PBKDF2 with more iterations become “more secure” indefinitely? It raises attacker cost linearly, but also your login cost linearly. The game is choosing the largest count your users will tolerate — that is what OWASP’s numbers calibrate.

Why is HKDF capped at 255 × hash size? The expand loop is T(i) = HMAC(PRK, T(i-1) || info || i) with a one-byte counter i — 255 is the largest counter value, a hard structural limit of RFC 5869, not a policy choice.

What is the difference between PBKDF2 on this page and the Password Hash Generator? Same algorithm, different job. This page derives raw key bytes for you to use elsewhere; the password-hash page produces stored-credential strings (with embedded salt and parameters) and verifies pasted candidates against them.