A keyed hash that proves both integrity and origin
The message 'order-42' signed with the secret 'dev-secret' using HMAC-SHA256 produces the hex signature 4a9c1201b226b3556d51e739a89a539ef3a425e7542c9b2df4d00702a4ea586a.
Unlike a plain hash, HMAC mixes a secret key into the hashing process -- which means verifying a message requires knowing the same secret, not just re-hashing the message text. That's what makes HMAC useful for proving a message actually came from someone who holds the secret (like verifying a webhook payload really came from the service that claims to have sent it), not just that the content hasn't been altered.
Changing either the message or the secret produces a completely different signature -- there's no partial-match or 'close enough' comparison in HMAC verification, which is exactly why webhook signature checks compare the full hex string for an exact match.
Where this fits in real webhook verification
Browser SubtleCrypto HMAC-SHA256. Compare is a lowercase hex equality check. This uses the browser's native SubtleCrypto API to compute a real, cryptographically correct HMAC-SHA256 -- unlike the JWT Token Generator's mock signer, this signature is genuinely verifiable against a server computing the same HMAC with the same secret and message.
The 'expected hex' comparison field does a simple lowercase hex string equality check -- useful for confirming your own manually-computed signature matches what a webhook provider sent, or for testing signature verification logic before wiring it into real server code.
Real production HMAC verification should always happen server-side with the secret stored securely (never exposed to a browser or client) -- this tool is for testing, debugging, and understanding the mechanism, not for verifying signatures on a live production endpoint.
Related cryptographic and API-testing tools
For a plain hash without a secret key (useful for simple integrity checks rather than origin verification), the Hash Generator (MD5/SHA) covers that simpler case.
If verifying a webhook's format and expected fields is the broader task, the Webhook URL Format Validator checks a different part of the same integration.
Frequently Asked Questions (FAQ)
How is this different from just hashing the message directly?
A plain hash (like SHA-256 alone) only proves content integrity -- anyone can recompute it. HMAC mixes in a secret key, so only someone who knows that secret can compute or verify the matching signature, which additionally proves the message's origin, not just that it wasn't altered.
Is this signature cryptographically real, unlike the JWT generator?
Yes. Browser SubtleCrypto HMAC-SHA256. Compare is a lowercase hex equality check. Unlike the mock JWT Token Generator, this tool computes a genuine HMAC-SHA256 using the browser's native SubtleCrypto API -- the output is a real, verifiable signature that a server computing the same HMAC with the same secret and message would match exactly.
How does the 'expected hex' comparison field work?
It performs a simple case-insensitive hex string equality check between the computed signature and whatever you paste into that field -- useful for confirming a webhook's provided signature matches what you compute locally with the shared secret.
Is it safe to test a real production secret in this browser tool?
Treat any secret entered here the way you'd treat any sensitive credential -- while the computation happens client-side in your browser, it's best practice to use a test or throwaway secret rather than a live production key whenever verifying logic in a general-purpose tool.
Why would changing even one character of the message completely change the signature?
Cryptographic hash functions (and HMAC, which is built on one) are designed so that any change to the input, however small, produces a drastically different, unpredictable output -- this avalanche effect is intentional and is part of what makes hash-based signatures secure against tampering.
