HMAC vs a Plain Hash: Webhook Signatures and Length-Extension
A plain hash proves nothing about who made a message: anyone can compute SHA-256(message). HMAC mixes a secret key into the hash so only a key holder can produce the value. The HMAC calculator computes it for SHA-256, SHA-512, SHA-1 and MD5.
Why not hash(key + message)
For MD5, SHA-1 and SHA-256 and SHA-512 (the Merkle-Damgard family), hash(key || message) allows length extension: someone who sees the digest and the message length can compute a valid digest for the message plus extra bytes without knowing the key. HMAC's two nested hashes with different padded keys closes that hole, which is why it is the standard construction.
Verifying a webhook
Services such as GitHub, Stripe and Slack send an HMAC-SHA256 of the raw request body in a header. To verify:
- Take the body bytes exactly as received, before any JSON parsing.
- Compute HMAC-SHA256 with your shared secret.
- Compare it to the header value with a constant-time comparison. Use the hash comparison tool only for manual checks; in code, use
crypto.timingSafeEqualor your language's equivalent.
Parsing and re-serialising the JSON changes whitespace and key order and breaks the match. That is the usual reason a signature "does not verify".
Key handling in the calculator
A text key is hashed as UTF-8. Tick "key is hex" when your secret is given as hex digits. Keys longer than the hash's block size (64 bytes, or 128 for SHA-512) are hashed first, as RFC 2104 specifies, so a 100-byte key and its digest give the same HMAC. Don't paste a production secret into any website; use a test key.
Which algorithm
HMAC-SHA256 is the default choice. HMAC-MD5 and HMAC-SHA1 are not broken by the collision attacks that ruined the plain hashes, but there is no reason to choose them for new work; they exist for compatibility with old protocols.