HMAC Generator

HMAC proves authenticity, a plain hash does not

Anyone can compute SHA-256 of a message, so a bare hash proves only that data was not corrupted. HMAC mixes a secret key into the hashing in a specific nested construction, so only someone holding the key can produce a valid tag. This is what makes it suitable for webhook signatures and API request signing.

Why the construction matters

Naively prepending a key and hashing is vulnerable to length-extension attacks against SHA-256 and similar constructions: an attacker can append data and compute a valid hash without knowing the key. HMAC's inner and outer hashing with derived pads closes that, which is why hand-rolled key-plus-message hashing is a real vulnerability rather than a style preference.

Compare in constant time

Verifying a signature with ordinary string equality leaks information through timing, because comparison stops at the first differing byte. Every platform provides a constant-time comparison; using it costs nothing.

Sign the raw bytes

The most common integration failure is signing a re-serialised payload. Frameworks parse JSON before your handler runs, and re-encoding changes whitespace and key order, so the recomputed HMAC never matches. Capture the raw body before middleware touches it.

Key length and algorithm

SHA-256 is the current default; SHA-1 remains cryptographically acceptable inside HMAC but is best avoided for new work. A key should be at least as long as the hash output — 32 random bytes for SHA-256 — and generated from a cryptographic source rather than chosen as a passphrase.