HMAC Generator
Compute an HMAC over a message with a secret key using SHA-1, SHA-256, SHA-384 or SHA-512.
Results are provided as is, for general information. Check anything important before relying on it. See the Terms of Use.
About this tool
HMAC (RFC 2104) is a keyed hash: it folds a secret key into a SHA-family digest so the result proves not just that a message wasn't altered, but that whoever produced it holds the key — which a plain hash can't do, since anyone can compute SHA-256 of a message with no secret at all. Enter a message and a key, pick SHA-1, SHA-256, SHA-384 or SHA-512, and get the digest as hex and Base64. Computation runs on the browser's native Web Crypto API (crypto.subtle), so the key never leaves the page. WebCrypto itself refuses a zero-length key, but RFC 2104 defines HMAC for one via zero-padding the key to the hash's block size — this tool does that padding itself so an empty-key HMAC matches the RFC 2104 result rather than being unsupported.
How it works
HMAC(K, m) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ m)) K = secret key, m = message, H = SHA-256 etc.
An HMAC hashes a message together with a secret key, so only someone holding the key can produce or verify the result. APIs use it to sign webhooks and requests. A plain hash cannot do this, because anyone can compute it.
| Question | Working | Answer |
|---|---|---|
| HMAC-SHA256 with key “key” of “The quick brown fox jumps over the lazy dog” | HMAC(“key”, message) using SHA-256 | f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 |
When to use it
Questions
What's the difference between HMAC and a plain hash?
A plain hash like SHA-256 takes no key — anyone can compute the SHA-256 of a message, so matching hashes only prove the message wasn't corrupted, not who sent it. HMAC weaves a secret key into the computation, so producing a valid HMAC requires holding that key. That's what makes it useful for verifying webhook signatures and API requests, where you need to know the sender is who they claim to be, not just that the bytes are intact.
Which SHA variant should I use?
Whatever the system you're integrating with specifies — HMAC output isn't interchangeable across variants, so HMAC-SHA256 and HMAC-SHA1 of the same message and key are completely different values, and verification fails silently if you pick the wrong one. SHA-256 is the common modern default (it's what JWT's HS256 uses); SHA-1 still turns up in legacy webhook signatures but is discouraged for anything new; SHA-384/512 show up where an API asks for extra digest length.
Why does the tool accept an empty key instead of rejecting it?
The browser's Web Crypto API throws "Zero-length key is not supported" if you hand it an empty key directly. RFC 2104 doesn't have that restriction — it defines HMAC for a zero-length key by padding it with zero bytes to the hash's block size (64 bytes for SHA-1/256, 128 for SHA-384/512) before use. This tool performs that padding itself, so an empty-key HMAC here matches what OpenSSL or any RFC-2104-compliant library would produce, rather than erroring out.
Does the secret key leave the browser?
No — the digest is computed by the browser's native Web Crypto API entirely on your device. Nothing is uploaded, so it's a reasonable way to test a real webhook secret without pasting it into a server you don't control.
Hex or Base64 — which output should I use?
Match whatever the system verifying the HMAC expects. Hex is more common in documentation, logs and debugging output; Base64 is more common in HTTP headers, since it's shorter. The tool shows both so you don't have to convert by hand.