Sign Messages with HMAC Using a Secret Key
A plain hash answers the question "did the bytes change?", but it answers it for anyone: an attacker who can modify a message can simply recompute the hash and attach a fresh one. HMAC closes that gap by mixing a secret key into the hash computation, so only someone who knows the key can produce a valid signature. The HMAC Generator computes HMAC-SHA256 and HMAC-SHA512 signatures for any message and key — the same primitive used to sign webhooks, authenticate API requests, and protect payment callbacks. Whenever two parties share a secret and need to trust that a message is authentic and unmodified, HMAC is the standard answer. Everything runs locally in your browser, so the key you enter never leaves your machine.
How to Create an HMAC Signature
- Paste the message you want to sign, such as the raw HTTP request body, into the message field.
- Enter the shared secret key that both sides agreed on in advance.
- Pick the hash function — HMAC-SHA256 is the common default for most integrations.
- Choose the key format, hex or plain text, to match what your API provider expects.
- Generate the signature and send it in the header your server requires, typically
X-SignatureorX-Hub-Signature-256. - Verify on the receiving side by recomputing the HMAC with the same key and comparing it against the received value.
Real Example: Signing a Webhook Payload
Imagine a webhook payload of amount=50&to=alice signed with the key s3cret-key. Both sides compute the same signature below; the receiver recomputes it from the raw body and rejects the request if the values differ by even one character.
| Field | Value |
|---|---|
| Message | amount=50&to=alice |
| Secret key | s3cret-key |
| Algorithm | HMAC-SHA256 |
| Signature | eec122ee0761c0c3b88c9d740cb79c6a83074fa7d5817e785b69de31dac6d053 |
| Same message, wrong key | An entirely different digest — the receiver detects the mismatch immediately |
Notice that the signature is just a hash — it does not encrypt anything. Anyone intercepting the message can read amount=50&to=alice in plaintext. What they cannot do is produce the correct signature without the key, which is what makes the message trustworthy.
Where HMAC Shines
- Webhook authentication — sign the raw payload so receivers can verify the event really came from the sender and was not tampered with in transit.
- API request signing — fold the method, path, and a timestamp into the message to prevent both tampering and replay attacks.
- Session cookies — a signed cookie value lets the server detect client-side edits without keeping server-side session state.
- Message authentication — any channel where both sides share a secret and need integrity plus authenticity, from IoT device firmware updates to service-to-service calls.
HMAC Best Practices
- Sign the exact raw bytes — never sign a pretty-printed version of the body; a single reformatted space breaks the signature.
- Use a long random key — at least 32 bytes from a cryptographically secure generator; short dictionary words can be brute-forced.
- Compare signatures in constant time — use a timing-safe comparison so the verification step itself does not leak information about the key.
- Include a timestamp — put
ts=...inside the signed message and reject anything older than a few minutes. - Rotate keys regularly — when a key leaks or an engineer leaves the team, issue a new key and update both sides promptly.
HMAC Questions and Answers
What does HMAC stand for?
Hash-based Message Authentication Code. It is a specific construction that combines a hash function such as SHA-256 with a secret key to produce a message signature.
How is HMAC different from a plain hash?
A plain hash has no key, so anyone can compute it for a modified message and pass it off as genuine. HMAC folds the secret key into the computation, so only key holders can produce a valid signature.
Do I need a different HMAC algorithm for different keys?
No. The algorithm choice is independent of the key. Use HMAC-SHA256 for most integrations, or HMAC-SHA512 when both sides prefer a longer digest.
Can HMAC be used for encryption?
No. HMAC authenticates a message but does not hide its contents. If you need confidentiality too, combine it with encryption, for example AES plus an HMAC tag.
What happens if the secret key is leaked?
Anyone holding the key can forge valid signatures, so treat a leak as a full compromise: rotate the key immediately and re-sign all outstanding messages.
Why does the same message produce a different HMAC than a plain SHA-256?
Because the key material is mixed into the computation. That is the entire point: the digest now depends on a secret that only the two parties share.
How long should the secret key be?
At least as long as the hash output — 32 bytes for HMAC-SHA256 — and generated randomly. Shorter keys reduce the attacker's search space.
Is HMAC-SHA256 secure?
Yes. It is widely deployed across webhooks, cloud APIs, and payment systems, and no practical forgery attacks exist when the key stays secret.
Should I sign the raw body or a hash of it?
Sign the exact raw bytes or an agreed canonical form. Some providers sign the body directly, others sign its SHA-256 hash first — match whatever your integration documents.
Can I reuse the same HMAC key for requests and responses?
You can, but keep the signed messages clearly distinct, for example by including a direction marker such as dir=request, so a captured response cannot be replayed as a request.