Hashes, IDs, and randomness
Debug the inputs to a webhook HMAC signature
Tools to use
A webhook's JSON looks correct, yet signature checking fails. Equivalent JSON meaning is not enough: HMAC combines a key with message bytes. Reordering keys or formatting whitespace may replace the exact body signed by the sender. Using a public practice key, we will identify which inputs must agree.
Check the calculation path with a known key and message
Select SHA-256 and hexadecimal output, key key, and message The quick brown fox jumps over the lazy dog, with no extra whitespace. The result should be the value below. This is public practice data, never a production secret. Passing a known small example separates basic calculation problems from request-specific problems.
f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8This is not the message's ordinary SHA-256, nor SHA-256 of a simple key-plus-message concatenation. If the protocol specifies HMAC-SHA-256, use that construction. Check the provider's specification rather than guessing SHA-384 or SHA-512 from the appearance of a signature.
Formatting JSON changes the signed bytes
These JSON documents mean the same thing, but spaces, newlines and key order alter HMAC input bytes. Parsing and stringifying or formatting before verification can fail to reproduce the sender's body. If the protocol signs the raw body, preserve and verify those raw bytes.
{"amount":100,"currency":"JPY"}
{ "amount": 100, "currency": "JPY" }LF and CRLF endings also differ. Byte counts or hexadecimal inspection help locate changes introduced by an HTTP library, file save, editor or copy operation. Binary bodies should not be casually decoded as text. This tool distinguishes raw file bytes from UTF-8 text input.
The same-looking key may represent different bytes
If a key is written as 6b6579, is that six text characters or three hexadecimal bytes? The latter decodes to key, but entering 6b6579 here does not automatically decode hex: the key field uses UTF-8 text. Base64-encoded keys require the same distinction. Matching printed characters does not necessarily match the intended key bytes.
Do not turn arbitrary binary keys into garbled text to force them into this field. Use a local implementation or provider SDK that accepts the exact bytes. Check key issuance, storage representation and decoding rather than changing keys until something matches. The displayed key byte count can reveal extra newlines or missing decoding.
The signed message may include more than the body
Some protocols sign a specified combination of timestamp, method, path and body. Hashing only the body cannot match those. Check separators, newlines, URL encoding and timestamp formatting in the provider's signing-string specification. This generic HMAC calculator does not automatically construct arbitrary webhook signing strings.
Hex, Base64 and Base64url look different. This screen outputs hex or Base64, so account for representation when comparing Base64url. A header may include a prefix such as sha256= that is not part of the digest itself. Follow the protocol's comparison rules instead of trimming characters until values appear similar.
A matching HMAC is only part of receiver verification
A matching result does not show whether a request is fresh or replayed. Replay handling using timestamps or identifiers, comparison implementation and key management belong to the receiver. This calculator does not complete webhook authentication. Fix algorithm, key representation, signed bytes and output format one at a time to isolate differences.
Share reproductions using a practice key and invented body, not production secrets in tickets or chats. Browser-local processing does not remove screen-sharing or clipboard risks. If a secret has been exposed, closing the page does not remedy it; follow the provider's or organization's rotation procedure. Begin with the public key in this example.
Check whether parsed JSON replaced the signed raw body
Parsing JSON and serializing it again before HMAC can change key order, whitespace, newlines or escape spelling. Structural equality and identical signed bytes are different checks. If the protocol signs the raw body, preserve that body for verification. Reformatting to make comparison easier can change the very message being compared.
Start with a public known key and a short known message, changing one variable at a time. If that fails, inspect algorithm, output format and key interpretation. If it passes but real data fails, inspect raw bytes and message construction. Avoid logging secret keys; use nonsecret properties such as encoding and length. This screen treats the key as UTF-8 text, not automatically decoded hexadecimal.
A matching MAC does not test replay defenses. Protocol timestamps, nonces or event IDs may require separate validation and deduplication in the receiver. HMAC is authentication with a shared key, not message encryption. Separate signature debugging from the design that safely processes an event once.