A real, verifiable HMAC signature over your payload
The payload {"event":"order.paid","id":42} signed with the secret 'whsec_dev' produces the HMAC-SHA256 hex signature cb666ba030d7597c02a876cc0e8277cc836bf54cd7a903771247662919815e1e.
This is the same algorithm many payment and webhook providers (notably Stripe-style signing) use to let a receiving server verify a webhook actually came from the claimed sender and wasn't tampered with in transit -- the receiver recomputes the same HMAC using the shared secret and compares it to the signature header sent with the request.
Changing even a single character in the payload -- a different order id, extra whitespace, a reordered JSON key -- would produce a completely different signature, which is exactly why webhook signature verification needs to operate on the exact raw request body, not a re-serialized or reformatted version of it.
What real providers add on top of this basic signature
Same algorithm as many Stripe-style signing secrets. No timestamp header is added. Real webhook signing schemes (like Stripe's) typically include a timestamp alongside the signature, and sign the concatenation of timestamp and payload rather than the payload alone -- this both proves recency (rejecting old, replayed requests outside an acceptable time window) and prevents a captured valid signature from being replayed indefinitely.
This tool signs raw text you paste in -- in a real integration, the exact raw request body bytes (not a re-parsed or reformatted version) must be what gets signed and verified, since even whitespace differences from JSON re-serialization would break the signature match.
Verification in production should always happen server-side with the secret kept out of any client-accessible code -- this browser tool is for testing and understanding the signing mechanism, not for signing real outbound webhooks from a production system.
Related signing and verification tools
For HMAC signing outside the webhook-specific context (a more general message-and-secret use case), the HMAC Signature Generator covers that.
If the concern is validating the webhook URL's format itself, separate from payload signing, the Webhook URL Format Validator checks that.
Frequently Asked Questions (FAQ)
Is this the same algorithm Stripe uses for webhook signatures?
Same algorithm as many Stripe-style signing secrets. No timestamp header is added. It uses the same HMAC-SHA256 algorithm, but Stripe's actual scheme also incorporates a timestamp into what gets signed, which this simplified tool doesn't add -- useful for understanding the core mechanism, not for exactly replicating Stripe's full signature format.
Why does a timestamp matter in real webhook signature schemes?
Including a timestamp in the signed content lets the receiving server reject requests outside an acceptable time window, which prevents a captured, valid signature from being replayed later by an attacker -- a signature with no timestamp component has no built-in expiration.
Does whitespace or key order in the JSON payload affect the signature?
Yes, significantly. HMAC signs the exact raw text provided -- any difference (extra whitespace, reordered keys, different formatting) produces a completely different signature, which is why real implementations must sign and verify against the exact raw request body bytes, not a re-serialized version.
Should I use this tool to sign real production webhooks?
No. This is meant for testing and understanding the signing mechanism. Production webhook signing should happen server-side with the secret kept out of any client-accessible code, using your actual application's server-side logic.
How would a receiving server actually verify a signature like this?
It recomputes the HMAC-SHA256 using the same shared secret over the exact raw payload it received, then compares that computed value to the signature sent in the request (typically in a header) -- a match confirms the payload came from someone holding the shared secret and wasn't altered in transit.
