HMAC Generator

Signing a message with a shared secret

HMAC produces a short tag that proves two things at once: the message was not changed, and it came from someone who knows the secret key. It combines a hash function (SHA-256, say) with the key in a specific nested construction, which is what separates HMAC from naively hashing the key and message together.

Why not just hash key plus message

Concatenating key + message and hashing it is vulnerable to length-extension attacks on Merkle-Damgard hashes like SHA-256: an attacker who sees one valid tag can append data and compute a new valid tag without the key. HMAC's inner and outer padding steps close that hole, which is why it is the standard for keyed authentication rather than a plain hash.

Example

HMAC-SHA256(key="s3cr3t", msg="pay=100&to=bob")
= 9f86d081884c7d659a2feaa0c55ad015
  a3bf4f1b2b0b822cd15d6c15b0f00a08  (hex)

The receiver recomputes the HMAC with the same key and compares. If the message or the key differs by one bit, the tag is completely different.

Where it shows up

Webhook providers sign payloads with HMAC so you can confirm a request truly came from them. API gateways sign requests to prevent tampering. JWTs using HS256 are HMAC under the hood (see the JWT verifier).

FAQ

Which hash should I pick? SHA-256 is the sane default. SHA-1 HMAC is still used in legacy systems and is not broken for HMAC the way SHA-1 collisions break signatures, but prefer SHA-256+ for new work.

Why compare tags with a constant-time check? A normal string compare returns early on the first mismatched byte, leaking timing that can reveal the tag byte by byte. Production verifiers use a constant-time comparison.

Does HMAC hide the message? No. It authenticates but does not encrypt. The message is still readable; HMAC only proves it is genuine and untampered.