HMAC Generator
Produce a keyed signature over a message. Anyone can recompute a plain hash, but only a holder of the shared secret can produce a matching HMAC, which is what makes it useful for proving where a payload came from.
This page opens in generate mode, computing through the Web Crypto API so the secret stays local.
Signing a webhook payload
The common use is emitting a signature a receiver will check. Sign the exact bytes of the request body, not a re-serialised version of the parsed object - key order and whitespace change the signature, and a receiver recomputing over different bytes will always disagree.
Many providers sign a composed string rather than the body alone, typically a timestamp and a version prefix joined with the payload. If you are reproducing a provider signature, that composition is usually the piece that differs.
Choosing hash and encoding
- SHA-256 - the default nearly everyone uses for webhook signatures.
- SHA-384 and SHA-512 - longer tags, often faster on 64-bit hardware; pick them only if a spec asks.
- Hex - the usual header encoding, case-insensitive and copy-paste safe.
- Base64 - about a third shorter, common where header size matters.
The key is not a password
HMAC does not stretch its key. A memorable passphrase is a guessable signature, so use random bytes - 32 is a sensible floor for SHA-256. Keys longer than the hash block size are hashed down first, so extreme length buys nothing.
Signing a URL rather than a body
Presigned URLs apply the same construction to a canonical string built from the method, path, expiry and selected headers, rather than to a request body.
Reproducing one means matching that canonical string exactly, character for character. Almost every failed signature reproduction is a difference in the string being signed rather than in the HMAC itself.