JSON Formatter
Pretty-print, validate and minify JSON with precise error positions.
Developer & Security
HMAC Generator
HMAC-SHA1, SHA-256, SHA-384 and SHA-512 with a secret key.
What it does. An HMAC proves both that a message is unaltered and that it came from someone holding a shared secret key. A plain hash proves only the first — anyone can recompute it. HMAC is what webhook signatures, API request signing and JWT HS256 tokens are built on.
Runs in your browserNothing uploadsNo signupWorks offline
How to use HMAC Generator
- Paste the message and the secret key.
- Pick the hash algorithm the receiving system expects.
- Copy the result as hex or Base64.
Why not just hash the key and message together
Because naive concatenation is breakable. Hashing key + message with older Merkle–Damgård hashes such as MD5, SHA-1 and SHA-256 is vulnerable to a length-extension attack: an attacker who knows the digest and the message length can append data and compute a valid digest for the extended message without ever learning the key.
HMAC exists to defeat exactly that. It hashes twice with two derived keys, which breaks the extension property.
This is not theoretical — the Flickr API signature forgery of 2009 was a real-world length-extension attack against exactly this mistake. If you are signing anything, use HMAC rather than assembling your own scheme.
Choosing the algorithm
| Algorithm | Use it when | Note |
|---|---|---|
| HMAC-SHA256 | Default choice | What most APIs specify |
| HMAC-SHA512 | Long-lived signatures | Faster than SHA-256 on 64-bit |
| HMAC-SHA1 | A legacy API requires it | Still safe in HMAC, not for hashing |
| HMAC-MD5 | Never, unless forced | Avoid |
SHA-1 is broken for collision resistance, which is why it is unfit for certificates and signatures. HMAC-SHA1 does not depend on collision resistance and is not considered broken — but new systems should specify SHA-256.
Verifying a webhook
The common use. A provider sends a payload plus a signature header; you recompute the HMAC over the raw body with your shared secret and compare.
Two details cause almost every failed verification. Compute over the raw request body, not a re-serialised object — reordering keys or changing whitespace changes the signature. And compare using a constant-time function rather than ===, because an early-exit comparison leaks timing information.
Encoding is the third: providers differ over hex and Base64, and getting it wrong produces a valid HMAC that never matches.
Frequently asked questions
What is the difference between a hash and an HMAC?
A hash proves the data is unaltered; anyone can compute it. An HMAC additionally proves the sender holds a shared secret, because it cannot be computed without the key.
Is my secret key sent to your server?
No. The computation uses the browser’s Web Crypto API locally. There is no request, which is the only acceptable design for a tool that handles keys.
Is HMAC-SHA1 safe?
For HMAC, yes — HMAC does not rely on collision resistance, which is what is broken in SHA-1. It remains unfit for certificates or digital signatures, and new systems should specify SHA-256.
Why does my webhook signature never match?
Almost always one of three things: you hashed a re-serialised body instead of the raw bytes, you used hex where the provider uses Base64, or trailing whitespace differs. Compare against the exact raw payload.
Should I compare signatures with ===?
No. Use a constant-time comparison. A standard string comparison exits at the first differing byte, which leaks how much of the signature was correct and allows it to be recovered a byte at a time.