HMAC Generator
Generate HMAC-SHA1, SHA-256, SHA-384 or SHA-512 signatures from a message and key, in hex and base64, computed locally.
Result
About HMAC Generator
HMAC proves a message came from someone holding the shared key and has not been altered. It is the mechanism behind webhook signatures, API request signing and TOTP codes.
Signing a request canonically
Every signature scheme defines a canonical string — the exact bytes both sides agree to sign. AWS SigV4 concatenates method, path, sorted query, selected headers and a payload hash; Stripe and GitHub webhooks sign a timestamp plus the raw body. The failures are almost always canonicalisation, not cryptography: a re-serialised JSON body, header order, or a trailing newline. Sign the raw bytes as received, before any parsing, and include a timestamp so a captured request cannot be replayed indefinitely.
Why HMAC rather than a plain hash
Hashing a secret concatenated with a message is vulnerable to length-extension attacks against Merkle-Damgård constructions such as SHA-256. HMAC's nested inner and outer hashing with derived pads eliminates that class of attack, which is why every serious protocol specifies HMAC rather than hash(secret + message).
Common use cases
- Reproducing a webhook signature to debug a verification failure.
- Signing an API request during development against a documented scheme.
- Verifying a payload received from a partner system.
Edge cases and gotchas
- The exact bytes signed matter - whitespace, ordering and encoding differences will change the signature. Sign the raw body, not a re-serialised object.
- HMAC-SHA1 is still cryptographically sound for message authentication, but new designs should use SHA-256.