HMAC — a hash only someone with the key can produce
Generate or verify an HMAC-SHA-256, SHA-384 or SHA-512 tag over text or a file, using a secret you hold. Unlike a plain hash, nobody without the key can produce a valid tag — which is what makes it useful for authenticating a message rather than just checking it arrived intact.
Processed locally in your browserNothing you enter here is uploaded, logged or sent to any server.
How an HMAC differs from a hash
A hash takes a message and produces a digest. Anyone can compute it, which is what makes it useful for detecting accidental corruption and useless for detecting deliberate change: an attacker who alters your file simply recalculates the digest and replaces that too.
An HMAC takes a message and a secret key. Without the key you cannot produce a valid tag, so a tag that checks out means the message came from someone who has the key and has not been altered since. That is authentication, not just integrity.
The construction is deliberately not "hash the key and the message together". SHA256(key ‖ message) is vulnerable to length extension — with common hash functions an attacker who has a valid tag can append data and produce a valid tag for the longer message without ever knowing the key. HMAC's nested structure, defined in RFC 2104, exists precisely to prevent that, and it is why you should never build your own.
Why verification is not just comparing two strings
Comparing tags with === stops at the first differing character, so how long the comparison takes depends on how many leading characters were right. An attacker who can measure that, and who can submit tags repeatedly, can work out the correct tag one character at a time without ever guessing the key.
This page hands the comparison to Web Crypto's own verify, which does not have that property. In a browser the risk is largely theoretical — you are not a network service being probed — but using the API that gets it right costs nothing at all.
Tested against the RFC's own vectors
The engine behind this page is checked against the published test cases in RFC 4231 — including case 6, where the key is longer than the hash's block size and must be hashed first, which is the case implementations get wrong. A round trip would not have caught it.
What this tool does not claim
No tool on this site is described as unbreakable, military grade, or completely secure, because none of those phrases means anything a person could check. What is written down instead is which standard is used, which library implements it, and what the tool has been tested against.
Everything here runs in your browser using its built-in Web Crypto implementation. Nothing is uploaded, and there is no server that could receive it. That is a real and checkable property — open your browser's network tab and use the tool.
What an HMAC does not give you
Non-repudiation. Both parties share the same key, so either could have produced any tag. If you need to prove who signed something, you need a digital signature, where only the holder of a private key can produce a signature and everyone with the public key can check it.
Confidentiality. The message is not hidden in any way. An HMAC sits alongside a message that anyone can read.
Replay protection. A valid tag stays valid forever. If a replayed message would cause harm, the message itself needs a timestamp or a counter inside the authenticated data.
Choosing a key
Random bytes, not a password. HMAC has no key-stretching step — the key is used directly — so a guessable key is guessable at full speed. Use the random generator to produce 256 bits and store it somewhere a person never types.
A key longer than the hash's block size (64 bytes for SHA-256, 128 for SHA-512) is hashed down first, so it adds length without adding strength. A key shorter than the output length reduces the security of the whole construction to the length of the key.
Related
Digital signatures when the two sides should not share a secret, or the hash calculator when there is no key involved at all.
Questions people actually ask
How is this different from a hash?
A hash needs no key, so anyone can compute it — which means an attacker who alters your file can recalculate the digest too. An HMAC needs a secret key, so a valid tag means the message came from someone who has that key and has not changed since. That is authentication rather than just integrity.
Why not just hash the key and the message together?
Because SHA256(key ‖ message) is vulnerable to length extension: with common hash functions, someone holding a valid tag can append data and produce a valid tag for the longer message without ever learning the key. HMAC's nested construction, defined in RFC 2104, exists specifically to prevent that. It is the standard example of why you should not build your own.
Does a valid tag tell me who sent the message?
No. Both sides share the same key, so either of them could have produced any tag — and so could anyone else who obtained it. If you need to establish who signed something, you need a digital signature, where only the private key holder can sign and everyone can verify.
What key should I use?
Random bytes, not a password. HMAC uses the key directly with no stretching step, so a guessable key is guessable at full speed. Generate 256 bits with the random generator and store it where a person never has to type it.
Why does the key format matter?
Because the same characters read as text and as hex are completely different keys. "deadbeef" as text is eight bytes; as hex it is four. If a tag will not match, this is the usual reason — far more often than an actual failure.
Is my key or message sent anywhere?
No. Both stay in the page and the computation is done by your browser's Web Crypto implementation. Nothing on this page reports to analytics, and the shared engine refuses to emit any event carrying a value of this kind.