A plain hash proves data hasn't changed — but it can't prove who created it, since anyone can compute the same hash. HMAC adds a secret key into the mix, producing a signature that proves both integrity and authenticity at once. This tool generates HMAC signatures for your input.
Solving a problem plain hashing genuinely can't
A standard hash function like SHA-256 is entirely public and deterministic — anyone with the same input can compute the identical hash, meaning a plain hash alone can't distinguish a message genuinely sent by an authorized party from one forged by an attacker who simply recomputed a matching hash for their own tampered message. HMAC (Hash-based Message Authentication Code), formally specified in RFC 2104 in 1997 by Mihir Bellare, Ran Canetti and Hugo Krawczyk, solves this by combining the message with a secret key known only to legitimate parties before hashing — meaning only someone who possesses that secret key can generate a valid HMAC for a given message, providing genuine authentication, not just simple integrity checking.
How this tool generates an HMAC
The tool combines your input message with a secret key you provide, processing them together through an underlying hash algorithm (like SHA-256) according to the HMAC construction defined in RFC 2104 — producing a signature that can only be reproduced by someone who knows both the exact original message and the exact secret key, providing a genuine authenticity guarantee that a plain hash of the message alone cannot offer.
Where HMAC is genuinely necessary
- API request authentication — many APIs require requests to be signed with an HMAC using a shared secret key, allowing the server to verify both that the request is genuinely authorized and that its content hasn't been tampered with in transit.
- Webhook payload verification — services sending webhook notifications commonly include an HMAC signature so the receiving system can verify the payload genuinely originated from the expected sender and wasn't forged or altered.
- JWT token signing — JSON Web Tokens frequently use HMAC (specifically the HS256 algorithm, HMAC combined with SHA-256) to sign tokens, ensuring a token's claims haven't been tampered with since being issued.
- Secure session or cookie signing — some web applications use HMAC to sign session data or cookies, detecting any unauthorized tampering with the stored value.
Frequently asked questions
What's the difference between a hash and an HMAC? A plain hash is entirely public and requires no secret — anyone can compute it from the message alone; an HMAC requires a secret key in addition to the message, meaning only parties who know that secret key can generate or verify a valid HMAC, providing genuine authentication rather than just tamper-detection.
How securely should the HMAC secret key itself be protected? Extremely carefully — the entire security guarantee of HMAC depends on the secret key remaining genuinely secret between authorized parties; if the key is exposed or leaked, an attacker could forge valid-looking HMAC signatures for their own tampered or fabricated messages.
Can HMAC use any underlying hash algorithm? Yes — HMAC is a construction technique that can be paired with various underlying hash functions (commonly SHA-256 today, though historically also MD5 or SHA-1), with the choice of underlying hash algorithm affecting the resulting HMAC's specific security properties and output length.
Further reading
RFC 2104 — HMAC — The original 1997 specification defining the HMAC construction and its security proof.
Wikipedia — HMAC — Detailed explanation of how HMAC combines a secret key with hashing to provide authentication.