Security Tools New Tool

Free Online HMAC Generator for SHA-256, SHA-1, SHA-384 and SHA-512

Work out an HMAC over any text with SHA-1, SHA-256, SHA-384 or SHA-512. The key can be read as text, as hex or as base64, which is the usual reason a webhook signature does not match, and the result is given as hex and base64 together. Paste the signature you were sent and the page says whether it agrees.

Free Forever Nothing Uploaded Key As Text, Hex Or Base64 Runs In Your Browser

Free Online HMAC Generator for SHA-256, SHA-1, SHA-384 and SHA-512

Advertisement Slot (Top Banner) Google AdSense Unit • Responsive Banner

HMAC Generator Everything happens in this tab. Nothing you paste is sent anywhere.

The message

The HMAC

Hex

Hex, upper case

Base64

Base64url

Algorithm SHA-256 is what almost every webhook uses.

Key

Compare

Buy Us A Coffee

Enjoying WizTools123? Help keep our server infrastructure 100% free and open for everyone.

Buy Us A Coffee

Sponsored Content (Below Tool) Google AdSense Placement

When a Webhook Signature Will Not Match

Four causes, and the first two are the common ones.

Almost every failed webhook check comes down to one of four things, and none of them is the HMAC arithmetic. Working through them in order is quicker than reading the provider docs again.

The key is not text. Plenty of providers give the signing secret as hex or base64. Feeding those characters to HMAC as text uses the wrong bytes and produces a perfectly valid HMAC of the wrong key. That is why this page makes you say which it is, rather than guessing. A hex secret is twice as long as the key it represents, so a 64 character secret is usually 32 raw bytes.

The message is not what was sent. The signature covers the raw request body, byte for byte. If your framework has already parsed the JSON and you re-serialise it to check, the bytes differ: key order, spacing after colons, escaped slashes, a trailing newline. Every web framework has a way to reach the raw body, and using it is the fix.

The forms do not match. One side produces hex, the other base64, and the strings look nothing alike even though the bytes are identical. Both forms are shown here side by side for exactly that reason. Some providers also prefix the value, such as a scheme name and an equals sign, which has to be stripped before comparing.

The signed string includes more than the body. Several providers sign a timestamp and the body joined together with a separator, and send the timestamp alongside the signature. If the documentation mentions a timestamp, the thing to hash is that joined string and not the body alone.

One thing to fix in your own code, not here. Compare signatures with a constant time function, such as hash_equals in PHP or compare_digest in Python, rather than with the ordinary equality operator. The comparison on this page is for your eyes and is not part of anyone security, but in a server that difference is a real timing attack.

How to Work Out an HMAC

A few steps, and nothing is uploaded.

Paste the message Exactly what was signed. For a webhook that means the raw request body, before any parsing, including a trailing newline if there is one.

Say what the key is Text, hex or base64. Getting this wrong is the most common cause of a mismatch, because the wrong reading still produces a confident looking HMAC.

Pick the algorithm SHA-256 unless the documentation says otherwise. SHA-1 is still used by some older providers and is acceptable inside HMAC, which is explained in the notes.

Compare with what you were sent Paste the signature into the compare box in any of the four forms. The page tells you which form it recognised and whether it agrees.

What to Know About HMAC

Including the three reasons a signature usually fails to match.

HMAC is not the same as hashing the secret and the message joined together. That older habit is broken against the SHA-1 and SHA-2 families, because their structure allows a length extension attack: someone who knows the hash of a secret plus a message can work out the hash of that message plus more of their own choosing, without ever knowing the secret. HMAC uses the hash twice with two derived keys, which closes that off. If you see code hashing a secret concatenated with a body, that is the bug.

HMAC with SHA-1 is still considered sound, even though SHA-1 itself is broken. What is broken about SHA-1 is collision resistance, which matters for signatures and certificates. HMAC does not depend on collision resistance, so HMAC-SHA1 remains acceptable and is still used by large providers. SHA-256 is the better default for anything new, and the page offers both without pretending the choice does not exist.

The key is bytes, not characters, and this page will not guess which you have. A secret written as 64 hex characters is 32 bytes, and reading those characters as text gives a 64 byte key and a different HMAC. Both answers look equally plausible, which is why the reading is a setting here rather than something inferred. If you are unsure, try all three and see which one matches the signature you were given.

This page computes an HMAC; it cannot tell you that a request is genuine. A matching signature proves the sender holds the key, nothing more. A replayed request carries a perfectly valid signature, which is why providers include a timestamp and expect you to reject old ones, and why the window you allow is your decision and not something a tool can check.

Key Features & Capabilities

What this tool does, and what it deliberately does not.

Four algorithms SHA-1, SHA-256, SHA-384 and SHA-512, all through the browser own Web Crypto.

The key read your way As text, as hex or as base64, with the byte length shown so you can sanity check it.

Every output form Hex in both cases, base64 and base64url, so no conversion is needed to compare.

Compares what you were sent Recognises any of the four forms, and strips a scheme prefix if there is one.

Explains the mismatch The four real causes of a failed webhook check, in the order worth trying.

Nothing uploaded A real signing secret can be used here without it leaving the tab.

About HMAC

An HMAC answers a narrow question: did this message come from someone holding the shared key, and has it been changed. It is the primitive behind webhook signatures, signed URLs, API request signing and session cookies, and it is built from an ordinary hash used twice with two keys derived from yours. That construction is what makes it safe where a plain hash of the secret and the message joined together is not.

This page exists mostly for debugging, because an HMAC that does not match is a miserable thing to chase. The arithmetic is never the problem: it is in the browser own cryptography here and in a vetted library at the other end. What differs is the input. The key is often hex or base64 and gets read as text, the message is often a re-serialised copy of the body rather than the raw bytes, and the two sides often disagree about hex versus base64. All three are visible on this page at once, which usually makes the answer obvious within a minute.

What the page deliberately does not do is pretend to validate anything. A matching HMAC tells you the sender had the key, and nothing about whether the request is fresh, whether it has already been processed, or whether the key has since been rotated. Those are decisions for the system receiving the request, and a tool that implied otherwise would be teaching the wrong lesson.

Frequently Asked Questions

Keys, output forms, and webhook signatures.

A plain hash takes one input; an HMAC takes a message and a key, and cannot be computed without the key. Hashing a secret and a message joined together looks like the same thing but is vulnerable to length extension against SHA-1 and SHA-2, which is the attack HMAC was designed to prevent.

Usually the key is hex or base64 and is being read as text, or the message is a re-serialised copy of the request body rather than the raw bytes. Those two account for most cases. The other two are hex against base64, and a provider that signs a timestamp joined to the body rather than the body alone.

Yes, within HMAC. SHA-1 is broken for collisions, which matters for certificates and signatures, but HMAC does not rely on collision resistance. Large providers still use HMAC-SHA1. For anything new, SHA-256 is the sensible default.

At least as long as the hash output, so 32 bytes for SHA-256. A longer key is hashed down first and gains nothing; a short key is padded and is simply weaker. If you are generating one, 32 random bytes written as hex or base64 is the normal answer.

No. The HMAC is computed in your browser by its own cryptography, with no request made. That is what makes it reasonable to use a real signing secret here, which you can confirm in the Network tab or by working offline.