An HMAC answers a different question than a plain hash does. A plain hash like SHA-256 alone proves data has not changed, but anyone can compute a plain hash of anything, so it proves nothing about who produced it. An HMAC mixes a shared secret key into the hashing process, so only someone who knows that key could have produced the correct output, which is what lets a webhook receiver, an API client or two systems that trust each other confirm both that a message is unaltered and that it genuinely came from the expected sender.
How HMAC differs from a plain hash
A plain hash function takes only a message and produces a digest. Anyone, including an attacker who intercepted a message in transit, can recompute that same hash over a tampered message and produce a digest that matches, as long as they simply attach the new hash alongside the modified content. That makes a plain hash useless on its own for authenticating where data came from.
HMAC solves this by folding a secret key into the hashing process through two passes defined precisely in RFC 2104, rather than simply concatenating the key and message and hashing once, which turns out to be vulnerable to a length extension attack against some hash constructions. Because producing a valid HMAC requires knowing the secret key, a receiver who shares that same key can recompute the HMAC over a received message and instantly detect if either the message or the signature was altered in transit.
- Plain hash: proves a message was not corrupted, proves nothing about who sent it.
- HMAC: proves both that a message was not altered and that the sender knew the shared secret.
- Widely used for webhook signature headers, API request signing and session token integrity.
- The strength of an HMAC depends entirely on the secrecy and randomness of the key, not just the hash algorithm.
Choosing SHA-256, SHA-384 or SHA-512 for HMAC
HMAC-SHA256 is the overwhelming default across webhook providers, API signing schemes and modern protocols, offering a strong security margin with fast computation and a manageable 64 character hexadecimal output. Running this hmac sha256 online is enough for the vast majority of integrations, and you should reach for it unless a specific system you are integrating with documents a different algorithm, since matching the exact algorithm the other side expects is required for the signatures to match at all.
HMAC-SHA384 and HMAC-SHA512 use a larger underlying hash and produce longer output, offering an even bigger theoretical security margin at a small computational cost. They appear in higher assurance protocols and some enterprise API integrations, but for the vast majority of webhook and API signing use cases, HMAC-SHA256 already provides more than enough security margin against any realistic attack.
Key formats: text versus hex, and why key length matters
A key entered as text is used exactly as its UTF-8 bytes, which is the natural choice for a human readable shared secret such as an API key string. A key entered as hex is decoded into raw bytes first, which matters when a system provides its signing secret as a hex encoded value, since treating that hex string as literal text instead of decoding it first will silently produce a completely different, incorrect HMAC.
Short or predictable keys weaken an HMAC regardless of how strong the underlying hash algorithm is, since an attacker's easiest path is often guessing the key itself rather than attacking the hash construction. This hmac generator recommends, as RFC 2104 does, a key at least as long as the hash output, which for HMAC-SHA256 means at least 32 bytes of real randomness, not a short, guessable password reused from somewhere else.
How this hmac generator works under the hood
The message and key are both passed to SubtleCrypto.importKey and SubtleCrypto.sign, part of the Web Crypto API built into every modern browser, with the HMAC algorithm and the chosen hash specified explicitly. This produces exactly the same output any standard server side HMAC implementation would produce for the same key, message and algorithm, since Web Crypto follows the same RFC 2104 construction.
Because the computation happens locally through a native browser API, the secret key you type is never transmitted anywhere, which matters given that people frequently use this kind of tool to debug a webhook signature using a real, live signing secret from a production system.
| Property | Plain hash (SHA-256) | HMAC-SHA256 |
|---|---|---|
| Requires a key | No | Yes |
| Proves data integrity | Yes | Yes |
| Proves sender authenticity | No | Yes, if the key is secret |
| Anyone can compute it | Yes | Only someone with the key |
How to use this hmac generator
- 1
Enter the message
Paste the exact message text the HMAC needs to be computed over, byte for byte.
- 2
Enter the secret key
Provide the shared secret as text or hex, matching the format the other system expects.
- 3
Choose the hash algorithm
Select SHA-256, SHA-384 or SHA-512 to match the algorithm the receiving system uses.
- 4
Choose the output format
Pick hexadecimal or Base64 to match the format expected in a header or field elsewhere.
Related tools worth bookmarking
Sources and further reading
- RFC 2104: HMAC: Keyed-Hashing for Message AuthenticationThe specification that defines the exact two pass construction this tool implements.rfc-editor.org
- MDN: SubtleCrypto.signThe Web Crypto method this tool calls to compute the HMAC using the browser's native implementation.developer.mozilla.org
- NIST FIPS 198-1: The Keyed-Hash Message Authentication CodeThe federal standard formalising HMAC alongside RFC 2104, including recommended key lengths.csrc.nist.gov
Frequently asked questions
Common questions about the hmac generator.
A plain hash proves only that data has not changed, and anyone can compute one over any content. An HMAC additionally mixes in a secret key, so a valid HMAC also proves the sender knew that key, which is what lets a receiver authenticate a message rather than merely check it for corruption.
The most common causes are a mismatched hash algorithm, an incorrectly formatted key, such as treating a hex encoded secret as literal text, or a message that differs by even a single byte from what the other system actually hashed, including invisible differences like trailing whitespace or line ending style.
Yes. A text key is used as its raw UTF-8 bytes, while a hex key is first decoded from hexadecimal into the actual bytes it represents. Using the wrong mode for a given key produces a completely different, incorrect HMAC even though the key looks identical on screen in both cases.
Use whatever algorithm the system you are integrating with documents, since the two sides must match exactly for the signatures to agree. When you control both sides and have a free choice, HMAC-SHA256 is the standard default, offering strong security with widely compatible, reasonably sized output.
Yes. Paste the exact raw payload and the shared signing secret, generate the HMAC with the algorithm the provider documents, and compare the result against the signature header the webhook actually sent. This kind of hmac signature verification usually explains a mismatch as either a modified payload or the wrong secret or algorithm being used.
No. The entire computation runs locally in your browser through the Web Crypto API, with no network request involved. This matters because people frequently test this tool using real, live signing secrets from production systems.