HMAC Generator
Calculate a keyed hash-based message authentication code for any message, and check signatures you receive. Choose the algorithm, enter the key as text, hex or Base64, and get the HMAC in hex, Base64 or Base64URL. Paste a signature from a webhook header, with or without a prefix such as “sha256=”, to verify it in constant time.
- Runs in your browser
- No sign-up
- Free to use
Computed in your browser. The key and message are never sent or stored. Use test secrets here rather than production keys.
How to use HMAC Generator
- Paste the message exactly, for webhooks the raw request body.
- Enter the secret key and say how it is encoded.
- Choose the algorithm and output format.
- Paste a received signature to verify it.
HMAC Generator features
Four algorithms
HMAC-SHA256, HMAC-SHA512, HMAC-SHA1 and HMAC-MD5.
Key encodings
Text, hexadecimal or Base64 keys.
Output formats
Hex, Base64 or Base64URL.
Signature check
Accepts hex or Base64 and common prefixes; constant-time comparison.
Exact bytes
Messages are hashed as UTF-8 exactly as entered.
Private
Computed in the browser; nothing is sent or stored.
When to use HMAC Generator
- Debugging webhook signature verification.
- Building signed requests to an API.
- Checking test vectors when implementing HMAC.
- Teaching how message authentication works.
HMAC Generator FAQ
What is an HMAC?
A hash-based message authentication code: a hash of a message combined with a secret key. Anyone with the key can verify that the message was produced by a key holder and not modified.
Why does my signature not match?
Most often the message differs by a byte: pretty-printed JSON instead of the raw body, a trailing newline, a different encoding. Also check the key encoding and the algorithm.
Is HMAC-SHA1 or HMAC-MD5 insecure?
As MACs they remain unbroken, because HMAC does not depend on collision resistance. They are considered legacy; new systems should use HMAC-SHA256.
What is the difference from a plain hash?
Anyone can compute a plain hash of a message. Only holders of the key can compute the HMAC, which makes it suitable for authentication.
Why compare signatures in constant time?
A comparison that stops at the first difference can leak information through timing. Servers should use a constant-time comparison; this tool does too.
Should I paste production secrets here?
The computation is local, but the safest practice is to use test secrets in browser tools and keep production secrets in your server environment.
Signing messages with a shared secret
When two systems share a secret key, HMAC lets one prove to the other that a message is authentic and unaltered. Payment providers, code-hosting platforms and messaging services sign their webhooks this way: they compute an HMAC of the request body with your secret and send it in a header, and your server recomputes it to check.
HMAC wraps a hash function in two passes with the key, which protects against attacks that affect plain hashes, such as length extension. Its security depends on the secrecy and randomness of the key and the strength of the hash, which is why SHA-256 is the usual choice today.
Most verification failures come from bytes, not cryptography. A web framework that parses the JSON body and serialises it again produces different bytes from those that were signed. Verification must use the raw body as received, the exact key bytes, and the algorithm the sender used.
On the server, compare signatures with a constant-time function, reject requests with missing or malformed signatures, and check timestamps where the sender includes them, to stop replays. Rotate shared secrets when staff with access leave.