HMAC generator

What an HMAC generator has to get right

An HMAC is a signature. You take a message, you take a secret both sides already know, and you produce a short string that proves two things at once: the message was not altered, and it was produced by someone holding the secret. Nearly every webhook you will ever receive is verified this way, which is why most people arrive here with a payload in one hand and a header in the other, trying to work out why their own code disagrees with the sender.

The arithmetic is the easy half, and every tool that does this gets it right. The half that goes wrong is the secret, because a secret key is a run of bytes and it is almost always handed to you as characters. Those are not the same thing, and choosing wrong does not produce an error. It produces a signature of the correct length, in the correct alphabet, that no server on earth will accept.

The key is bytes, not letters

Suppose your provider gives you a 64-character secret made only of the digits 0 to 9 and the letters a to f. That is almost certainly a 32-byte key written in hexadecimal. Read as text it becomes 64 bytes instead, every one of them the ASCII code of a digit rather than the value it stands for. Both readings run happily. Only one matches the server.

So the key field here has its own reading: Text, Hex or Base64, independent of the message. The receipt then reports how many bytes the key came to, and that number is the whole point of it being there. If your provider documents a 32-byte secret and the receipt says 64, you have found the bug without touching your server code. Base64 is on the list for the same reason — several storage and messaging APIs hand out keys in that encoding, and if you want to look at one on its own, decoding the Base64 shows you the bytes it stands for.

The message has the same three readings, and the reason is narrower but just as sharp: a payload sometimes arrives as a hex dump rather than as text. There is one more trap in the message that no setting can remove. A text box in a browser rewrites CRLF line endings to LF, because the HTML specification says it must, and line endings are bytes like any other. A payload that was signed with Windows line endings and pasted into a text box will not match. When the exact bytes matter, hand over the file instead — the file path reads it as it sits on disk, in slices, so a large one neither loads into memory nor gets refused.

Hex, Base64, and why you get both

The signature is shown in both encodings at once because you usually cannot tell in advance which one you need. GitHub and Stripe compare hexadecimal. Shopify and several AWS-adjacent services compare Base64. They are not two results: they are the same bytes from a single run, written two ways, which means you can copy either one without wondering whether they drifted apart.

If you already hold the signature you were sent, paste it into the check field and the comparison becomes the answer instead of the signature. Paste it in whatever form it arrived — a bare hex string, Base64, a sha256= prefix, or a whole multi-field header — and the label is read off and reported. Comparing two 64-character strings by eye is exactly the task people do badly and machines do perfectly, and a near-match means nothing at all: one changed bit in the message changes half the output.

A mismatch is not the same answer as an unreadable signature, so the two are never blurred together. If what you pasted is not the right length for the algorithm you selected, you are told that rather than told it does not match — otherwise you would go hunting through your server for a bug that was a menu choice.

Which algorithms, and the ones that are missing

SHA-256 is the default and the right answer for anything new. SHA-1, SHA-384 and SHA-512 are here because APIs still use them, and MD5 is here because older systems still emit HMAC-MD5 and you occasionally have to check one. HMAC holds up far better under MD5's weaknesses than a bare MD5 digest does, but that is a reason to verify an old signature, not a reason to choose it. If what you actually need is a plain digest of a file rather than a keyed signature, the SHA-256 checksum and the MD5 checksum pages do that job without a key at all.

SHA-224 and the SHA-3 family are absent, and the reason is worth stating rather than hiding: the browser's own cryptography engine does not implement them, so there is no hash here to build the construction on top of. A menu entry that quietly produced nothing would be worse than a gap you can see. Block-cipher MAC modes such as DES, RC5, IDEA and GOST are also absent, and those are a different thing altogether — they are not HMAC, and no webhook documentation asks for them.

A closely related case has its own page. If your signature arrives attached to a JSON Web Token rather than to a webhook body, the token carries its own header, payload and signature, and decoding the JWT shows you all three before you try to verify anything.

Why the key never leaves this tab

A signing secret is the one credential that lets anyone forge messages your systems will trust, so pasting it into a web page deserves suspicion. Everything on this page runs in your browser: the key is never sent anywhere, never written into the address bar, never stored in this browser, and never repeated back inside an error message — which is why an error about a bad hexadecimal digit names the position and not the character.

You do not have to take that on faith, and you should not. Open your browser's network panel before you type, then watch it stay empty while the signature appears. The check takes half a minute and it works on any site making the same promise, which is worth knowing because not all of them keep it: at least one tool ranking on the first page for this term posts your secret key to its own server in order to answer. The longer version of that check, and what it does and does not prove, is written up in how to verify that a page really processes files locally.

One last thing this page deliberately does not do: there is no reverse. HMAC is not encryption and has no inverse, so an "HMAC decoder" cannot exist — the output throws information away on purpose. What you can do is recompute and compare, which is the whole of what verification ever means.