How to Generate an HMAC Signature Online

A webhook lands in your app with an X-Signature: sha256=... header, and your job is to recompute that same HMAC from the raw request body and a shared secret to confirm it actually came from the service that claims to have sent it. If your computed signature doesn’t match, you either reject the request as forged or — more often when you’re first setting this up — you’ve made a small mistake somewhere in how you’re hashing the message.

Before writing that verification logic into your app, it helps to sanity-check the algorithm by hand: take a known message and secret, compute the HMAC with a trusted tool, and confirm your code produces the same output. That’s a five-second check with the right tool, and a genuinely annoying one without it — most people’s instinct is to open a language REPL and import a crypto library just to test one string.

What an HMAC actually verifies

HMAC (Hash-based Message Authentication Code) combines a secret key with a message and a hash function (SHA-1, SHA-256, SHA-384, or SHA-512) to produce a fixed-length signature. Anyone who knows the secret can recompute the same signature from the same message; anyone who doesn’t know the secret can’t forge a matching one, even if they can see the message itself. This is why webhook providers — payment processors, source control platforms, messaging APIs — use HMAC to let you verify a request’s authenticity without encrypting the payload.

The two things that have to match exactly between sender and receiver are the algorithm (SHA-256 vs. SHA-1 produce completely different signatures for the same input) and the exact byte content of the message — including things like trailing whitespace or line-ending differences that are easy to introduce by accident.

Why people get stuck here

• Signing the wrong representation of the message. Hashing a re-serialized JSON object instead of the exact raw request body produces a different signature even if the data looks identical.
• Algorithm mismatch. Using SHA-1 when the provider’s docs specify SHA-256 gives a signature that will never match, with no error message explaining why.
• Hex vs. Base64 output confusion. The same HMAC computation produces different-looking output depending on whether it’s encoded as hexadecimal or Base64 — comparing a hex signature against a Base64 one will always fail.
• Key encoding mismatches. If the secret key is meant to be used as raw bytes but you accidentally pass its hex or Base64 string representation instead, the signature comes out completely different.
• Trailing newline differences. A message copied from an editor that appends a trailing newline hashes differently than the same string without one.

What a good HMAC generator looks like

Support for all common hash algorithms

SHA-1 for legacy compatibility, and SHA-256, SHA-384, and SHA-512 for anything current — a tool that only supports one algorithm won’t match every provider’s requirements.

Both hex and Base64 output side by side

Since different services encode signatures differently, seeing both outputs at once avoids a re-run just to check the other format.

Processing that happens locally

Since the whole point of HMAC is a shared secret, pasting that secret into a tool that uploads it to a server undermines the reason you’re using HMAC in the first place.

Common mistakes to avoid

• Testing with a message that includes extra whitespace or a different line ending than what your actual code will send, producing signatures that never match in practice.
• Assuming HMAC-SHA256 and SHA256 (a plain hash with no key) are interchangeable — they are not, and confusing them is a common source of “why doesn’t my signature match the docs’ example” bugs.
• Hardcoding a webhook secret directly into client-side code where it’s visible to anyone — HMAC secrets belong server-side only.
• Comparing signatures with a naive string equality check in production code instead of a constant-time comparison, which can leak timing information about the correct signature.
• Forgetting that changing even one character in the message — including case sensitivity in JSON keys — produces a completely different signature, by design.

How to do it with HMAC Generator

Online Tool Store’s HMAC Generator uses the browser’s built-in Web Crypto API, so the message and key never leave your device.

1. Paste the exact message or payload you want to sign.
2. Enter the secret key.
3. Choose the hash algorithm — SHA-1, SHA-256, SHA-384, or SHA-512 — to match what the provider or your own system expects.
4. Copy the resulting signature in hex or Base64, whichever format you need to compare against.

Frequently asked questions

Is HMAC the same as encryption?

No. HMAC proves the message hasn’t been tampered with and came from someone who knows the shared secret, but it doesn’t hide the message content itself — the payload is still sent in plain text alongside the signature. Use encryption separately if the content itself needs to stay confidential.

Why doesn’t my computed signature match the one in a webhook header?

The most common causes are: signing a re-serialized version of the payload instead of the exact raw bytes received, using the wrong hash algorithm, or a mismatch between hex and Base64 output. Double-check each of those against the provider’s documentation before assuming the secret itself is wrong.

Which hash algorithm should I use for new integrations?

SHA-256 is the standard default for new HMAC implementations — strong enough for current use and supported everywhere. SHA-1 still shows up in older APIs for backward compatibility, but avoid choosing it for anything new.

Final thought

An HMAC signature is only useful if both sides compute it the exact same way — same algorithm, same key encoding, same message bytes. When a signature mismatch has you stuck, isolate the variables one at a time with a known-good tool before assuming the bug is somewhere more complicated.

Try the free HMAC Generator tool