HMAC Generator
Message plus shared key, out comes the signature. SHA-256 and SHA-512, computed with WebCrypto.
—
Worked example
Webhook providers sign the raw request body, not the parsed JSON. Re-serialising the payload before verifying changes whitespace and key order, and the signature fails — a common cause of "webhook signature invalid" when the secret is actually correct.
An HMAC combines a message with a secret key so that anyone holding the key can verify the message has not been altered, and anyone without it cannot forge a valid tag. Unlike a plain hash, an attacker who can compute hashes still cannot produce the tag without the key.
Verifying a webhook signature
Take the raw body exactly as received — the bytes before any JSON parsing or pretty-printing. Put it in the message box, put the shared secret in the key box, and pick the algorithm the provider documents. Compare the output against the signature header. Comparison must be case-insensitive and, in real code, constant-time.
Common mismatches
Three things break HMAC verification more often than anything else: re-serialised JSON, a secret that was base64-decoded when it should be used as-is (or the reverse), and a signature that is prefixed with an algorithm name such as sha256= that must be stripped before comparing.
What HMAC does not give you
It does not hide the message — anyone can read it. It does not prevent replay: a captured valid request stays valid forever unless the payload carries a timestamp or nonce that the receiver checks. And it offers no forward secrecy; if the key leaks, every past message can be re-signed.