HMAC Generator

What is HMAC?#

HMAC stands for Hash-based Message Authentication Code. A plain hash (like SHA-256) answers the question “did this byte stream change?”. HMAC answers a stronger one: “did this byte stream change, and was it sent by someone who actually shares my secret key?”. The difference matters whenever a message travels over a channel you do not fully trust — webhook callbacks, signed URLs, API request signing, inter-service tokens.

Mechanically, HMAC mixes a secret key into the hash function in a defined way (two rounds, with padding) so the digest cannot be forged without the key. The output is a fixed-length byte string whose size matches the underlying hash: 20 bytes for SHA-1, 32 for SHA-256, 48 for SHA-384, 64 for SHA-512.

This page computes HMAC in your browser using the Web Crypto API. You pick the hash, paste the message and the secret, and get the digest as hex or base64.

How to use it#

1. Type or paste the Message — the payload you want to authenticate. This is the bytes the receiver will hash on their side.
2. Enter the Secret key. The field is masked by default; click the eye button on the right to reveal it while you type. Both key and message are encoded as UTF-8.
3. Choose the Algorithm:
   • SHA-1 — 160-bit. Fast, but only suitable for legacy HMAC (some older signing flows still mandate it). Do not use SHA-1 for digital signatures.
   • SHA-256 — 256-bit. The modern default; the vast majority of webhook signatures (Stripe, GitHub, Slack-style flows) use HMAC-SHA-256.
   • SHA-384 / SHA-512 — longer digests, marginally more collision resistance, slightly slower. Pick one when the receiving system explicitly requires it.
4. Choose the Output encoding: hex (typical for X-Signature-style headers) or base64 (typical when the digest is embedded in JSON or a token).
5. Click Generate. The digest appears in the right pane; the status line shows the algorithm and the byte length as a sanity check. Copy to grab it.

Key features#

• Backed by Web Crypto. Uses the browser’s native crypto.subtle, the same primitive production code uses — not a JavaScript reimplementation.
• Length sanity check. Every digest is verified against the expected byte length for its algorithm, so a truncated or tampered result cannot silently slip through.
• Hex or base64 output. Switch with one click; no re-typing.
• Secret stays local. The key field is rendered as a password input and never leaves the page — there is no backend.
• Secure-context aware. If the page were ever loaded over plain HTTP, crypto.subtle is unavailable and the tool reports that explicitly instead of producing a wrong answer.

Worked example#

The classic reference pair (RFC 4231) uses a key of Jefe and the message what do ya want for nothing?. With this page set to SHA-256 and hex, the digest is:

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

Switch to SHA-512 with the same inputs and the digest doubles in length:

164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737

You can reproduce both right here: load Sample, then Generate. This exact pair is also how this tool’s own test suite verifies correctness — if you ever get a different digest, something has tampered with the page.

FAQ#

SHA-256 or SHA-512 — which should I use?#

For HMAC specifically, SHA-256 is the pragmatic default: every major webhook signer uses it, it is fast, and 256 bits of digest is already far beyond brute-force territory. Move to SHA-512 only when (a) the receiving system requires it, or (b) you are designing a new protocol from scratch and want the extra collision margin at a modest speed cost. Avoid SHA-1 entirely unless you are matching a legacy system that mandates it.

Is HMAC the same as encrypting the message?#

No. HMAC only authenticates — it proves the message was not altered and came from someone holding the key. The message itself stays in plain text. If you need confidentiality too, pair HMAC with an encryption scheme, or use an authenticated-encryption mode like AES-GCM.

Can the secret key be recovered from the digest?#

No. The digest is a one-way function of both the message and the key; recovering the key from outputs is computationally infeasible. That said, a short or guessable key can still be brute-forced by trying candidate keys offline — so use a key with at least 128 bits of real entropy, not a human-chosen password.

The receiver says my signature does not match. What do I check first?#

Nine times out of ten it is the byte representation of the message: trailing newlines, URL-encoding versus raw body, JSON whitespace, or a different field order. Compare the exact bytes you signed against the exact bytes the receiver hashed, character for character, before checking anything else.