My signature does not match the provider's. Why?

In order of likelihood: the body has been parsed and re-serialised so the bytes differ, the encoding is hexadecimal where they used Base64, or the provider signs a constructed string such as a timestamp joined to the payload rather than the payload alone. Capture the raw body before any middleware touches it and retry.

How is this different from just hashing the message?

A hash proves the message is unchanged; anyone can compute one. An HMAC proves the message came from someone holding the key, which is a claim about origin rather than integrity. It is also specifically constructed to resist length-extension attacks that naive key-then-message hashing is vulnerable to.

Is HMAC-SHA-1 safe to use?

For verifying existing systems, yes — HMAC's construction holds up even though SHA-1's collision resistance does not. For anything new, use SHA-256, because there is no reason to build on a primitive being phased out everywhere else.

Does my secret key leave the browser?

It does not. The key is imported into your browser's own cryptography engine and used there. Nothing is transmitted, which is what makes it reasonable to paste a live webhook secret into this page while debugging.

HMAC Generator

Sign a message with a secret key using HMAC-SHA.

Everything runs inside your browser. Your files never leave your device.

Input

Result

The result appears here as you type.

Ask about HMAC Generator

Questions about what this tool does, which option to pick, or what it can and cannot handle.

The question you type here is sent to an AI provider to be answered — your files and whatever you put in the tool above are not, and the assistant cannot see them. Answers are generated and can be wrong. The tool itself is not guessing: it runs deterministic code on your device.

About the HMAC Generator

An HMAC answers a question a plain hash cannot: not merely whether a message is intact, but whether it came from someone who knows a shared secret. It combines the message with a key in a specific nested construction, so a digest can only be produced — and only checked — by a party holding that key.

This is the mechanism behind almost every webhook signature you will ever integrate. Stripe, GitHub, Shopify, Slack and most others sign their payloads with HMAC-SHA-256 and send the result in a header. Your endpoint recomputes the HMAC over the raw body using the secret they gave you, compares the two, and rejects the request if they differ. Without that step, your webhook endpoint will process anything anyone sends it, which is a very short path to a serious incident.

The tool computes HMAC-SHA-256, SHA-384, SHA-512 or SHA-1 over your message with your key, in hexadecimal or Base64. Its most common use is debugging that comparison: you have a payload, a secret and a signature the provider sent, and you need to find out why yours does not match theirs.

When it does not match, the cause is usually one of three things, and none of them is the algorithm. The body must be the exact raw bytes received, before any JSON parsing and re-serialisation — reordered keys or changed whitespace produce a completely different digest. The encoding must match what the provider used, hexadecimal or Base64, and lowercase or uppercase where hexadecimal is concerned. And some providers sign a constructed string rather than the body alone, typically a timestamp and the payload joined by a separator, which their documentation will specify and which is easy to miss.

In production, compare signatures with a constant-time function rather than string equality, so the comparison itself does not leak the answer through its timing.

How to use it

1Paste the exact message being signed into the input — the raw request body, byte for byte.
2Enter the shared secret in the key field.
3Choose the algorithm your provider specifies. HMAC-SHA-256 is the near-universal choice.
4Match the output encoding to what you are comparing against, then check the two digests agree.

Questions

My signature does not match the provider's. Why?: In order of likelihood: the body has been parsed and re-serialised so the bytes differ, the encoding is hexadecimal where they used Base64, or the provider signs a constructed string such as a timestamp joined to the payload rather than the payload alone. Capture the raw body before any middleware touches it and retry.
How is this different from just hashing the message?: A hash proves the message is unchanged; anyone can compute one. An HMAC proves the message came from someone holding the key, which is a claim about origin rather than integrity. It is also specifically constructed to resist length-extension attacks that naive key-then-message hashing is vulnerable to.
Is HMAC-SHA-1 safe to use?: For verifying existing systems, yes — HMAC's construction holds up even though SHA-1's collision resistance does not. For anything new, use SHA-256, because there is no reason to build on a primitive being phased out everywhere else.
Does my secret key leave the browser?: It does not. The key is imported into your browser's own cryptography engine and used there. Nothing is transmitted, which is what makes it reasonable to paste a live webhook secret into this page while debugging.