ToolLineup

HMAC Generator

This HMAC generator produces a keyed hash of a message — the signature behind webhook verification and API request signing. The distinction from a plain hash is the whole point: anyone can hash a message, but only someone holding the secret key can produce the matching HMAC, which is what lets a receiver confirm both who sent a payload and that it has not been altered in transit. The key can be given as text, base64 or hex, which matters because webhook secrets are usually plain text while API signing keys are often distributed encoded, and reading one as the other produces a completely different and completely wrong signature.

How it works

HMAC is a hash with a key mixed in, which is what makes it useful for signatures rather than just fingerprints. Anyone can hash a message; only someone with the key can produce the matching HMAC, which is how webhook signatures and API request signing work.

The key can be given as text, as base64 or as hex — webhook secrets are usually text, while API signing keys are often distributed as hex or base64, and reading one as the other produces a completely different result.

Everything runs in your browser using its own cryptography — nothing is sent to a server.

Message
Paste here…
Signature

Hash versus HMAC

A hash proves a message has not changed, but only if you already know the correct hash from a trusted source. Anyone who alters a message can also recompute its hash.

An HMAC adds a secret key. Without the key, an attacker can alter the message but cannot produce a signature that matches — which is why every webhook provider signs payloads this way.

Verifying a webhook, in order

  1. Take the raw request body, before any parsing or reformatting.
  2. Compute the HMAC using your webhook secret and the provider's algorithm.
  3. Compare against the signature header using a constant-time comparison.

Step 1 is where most failures come from. Parsing JSON and re-serialising it changes the bytes — key order, whitespace, number formatting — and the signature no longer matches.

Constant-time comparison

A normal string comparison stops at the first differing byte, so it returns faster for a wrong signature that shares a longer prefix. Repeated attempts leak enough timing information to reconstruct a valid signature. Every language has a constant-time compare for exactly this reason — use it.

Frequently asked questions

What is HMAC?

A hash with a secret key mixed in. Anyone can hash a message, but only someone with the key can produce the matching HMAC, which is what makes it a signature rather than a fingerprint.

How do I verify a webhook signature?

Compute the HMAC of the exact raw request body using your webhook secret and the algorithm the provider specifies, then compare it to the signature header. It must be the raw body — any reformatting changes the result.

Why does the key encoding matter?

A key given as hex is bytes, not characters. Reading "4a6566" as text gives six bytes; reading it as hex gives three. The signatures differ completely, and this is the most common cause of a verification that will not pass.

Which algorithm should I use?

SHA-256 unless the service you are working with specifies otherwise. SHA-1 is still used by some older APIs and is fine for HMAC specifically, but there is no reason to choose it for something new.

Should I compare signatures with ==?

Not in production code. Use a constant-time comparison, because a normal string comparison returns early on the first differing byte and leaks timing information an attacker can use.

Is my key sent anywhere?

No. The HMAC is computed by your browser own cryptography and neither the key nor the message leaves your device.

Related tools