HMAC Generator & Verifier

HMAC vs a Plain Hash vs a Digital Signature

A plain hash like SHA-256 proves a message hasn't been altered, but proves nothing about who produced it — anyone can compute a matching hash over any content, including tampered content. HMAC closes that gap for symmetric-secret scenarios: it folds a shared secret key into the hashing process, so only someone who holds that secret can produce a tag that verifies correctly, which is exactly the property needed when a receiving server needs to confirm a webhook genuinely came from the platform that claims to have sent it. A public-key digital signature (RSA or ECDSA, as used in TLS certificates and code signing) solves a related but distinct problem: it lets anyone verify authenticity using a public key, without ever needing access to the private signing key — useful when the verifier and signer are different, unrelated parties who've never exchanged a shared secret. HMAC is the simpler, faster, and generally correct choice whenever both sides can safely share one secret in advance, which is true for essentially every webhook-signing scenario; asymmetric signatures earn their extra complexity only when verification needs to happen without ever distributing anything secret at all.

Handling Secrets and Signatures Correctly

• Sign the raw request bytes, never a re-serialized copy: if a webhook handler parses the body into an object and re-serializes it before comparing signatures, differing key order or whitespace between the original payload and the re-serialized version produces a different HMAC and a false-negative failure — capture and sign the exact bytes received, before any JSON parsing.
• Compare signatures with a timing-safe function: a standard string-equality check short-circuits on the first mismatched character, which leaks timing information an attacker can exploit across enough requests to reconstruct a valid signature without ever knowing the secret.
• Store the secret in a secrets manager, not a baked-in environment variable: Vault, AWS Secrets Manager, or a CI/CD platform's encrypted secrets store keep a leaked container image layer from also leaking the webhook secret it was built with.
• Support two active secrets during rotation: verify incoming signatures against either the old or new secret for a transition window, since most webhook-sending platforms have no built-in zero-downtime rotation mechanism of their own.

Signing at Volume

HMAC computation itself is cheap — SHA-256 based HMAC processes payloads fast enough that signature verification is rarely the bottleneck in a webhook receiver, even at high request volume. Where performance actually matters is the surrounding plumbing: verifying a signature correctly requires buffering and hashing the complete raw request body before any JSON parsing begins, which means a receiver handling large payloads or a high sustained request rate needs to budget memory for holding the raw body rather than streaming straight into a parser. Any implementation using a non-timing-safe string comparison for the final checkadds a subtler cost under adversarial load — timing side-channel attacks work by sending enough requests to statistically extract information from tiny response-time differences, so an endpoint sees no functional slowdown from this vulnerability until an attacker starts actively probing it with the volume of requests needed to make the timing signal statistically usable, at which point the fix is procedural (use a constant-time comparison), not about scaling hardware.

When Signatures Don't Match

The most common "valid secret but invalid signature" report traces back to encoding, not the secret itself: a secret copy-pasted from a terminal or a .env file often carries an invisible trailing newline character, and that single extra byte produces a completely different HMAC than the same secret without it. Checking for stray whitespace or newlines around the secret before assuming it's wrong resolves this far more often than re-generating or rotating the secret does. A second frequent cause is exactly the re-serialization problem described above — computing the comparison HMAC over a parsed-then-re-stringified version of the payload rather than the original raw bytes, which silently diverges whenever key order or whitespace differs even slightly from the original. A third, less common cause is an algorithm mismatch — expecting HMAC-SHA256 while the sender actually signed with HMAC-SHA1 or SHA512 — which is easy to rule out quickly by generating the signature with every supported algorithm and checking which one actually matches the value received.

Frequently Asked Questions