# HMAC Generator (SHA-256/384/512)

> Compute a keyed HMAC over a message with your secret key, shown as hex and Base64, via the browser's native Web Crypto. The same construction the JWT verifier uses for HS256. Your key never leaves your browser.

- Tool: https://ronutz.com/en/tools/hmac
- Family: Hashing & crypto

---

## What it does

Compute an HMAC, a keyed hash, over a message using a secret key, with the result shown as hexadecimal and Base64. You choose SHA-256, SHA-384, or SHA-512 as the underlying hash. The computation uses the browser's native Web Crypto, and your key never leaves your browser. This is the same construction, over the same code path, that the JWT verifier uses to check an HS256 signature, so the two agree by design.

## What HMAC is for

A plain hash proves that data has not changed, but anyone can recompute it, so it cannot prove who produced it. HMAC adds a secret key to the hash, which turns it into a message authentication code: a value that proves both that the message is intact and that it came from someone who holds the key. The sender computes the HMAC and sends it alongside the message; the receiver, who shares the key, recomputes it and checks that the two match. It is defined in RFC 2104 and FIPS 198-1, with test vectors in RFC 4231.

## Symmetric by nature

HMAC uses one shared secret for both producing and verifying the code. That makes it fast and simple, but it also means anyone who can verify an HMAC can also forge one, because both operations use the same key. It is the right tool when the same party, or two parties that already share a trusted secret, both produce and check the codes. When independent parties must verify without being able to forge, an asymmetric signature is the better fit, which is the same trade-off that separates HS256 from RS256 in JWTs.

## How it is built

HMAC is not simply the hash of the key joined to the message, which would be vulnerable to length-extension attacks. It is a nested construction: the message is hashed together with one derived form of the key, and that result is hashed again with a second derived form. This structure is what gives HMAC its security proof, and it is why you should use HMAC rather than inventing your own keyed hash.

## Using it

Enter a message and a secret key, pick the hash, and read the HMAC as hex or Base64. Feed the same message and key to two systems and the codes will match; change either the message or the key by one character and the code changes completely.

## Standards and references

- [RFC 2104 - HMAC: Keyed-Hashing for Message Authentication](https://www.rfc-editor.org/rfc/rfc2104) - the HMAC construction
- [RFC 4231 - HMAC-SHA Identifiers and Test Vectors](https://www.rfc-editor.org/rfc/rfc4231) - HMAC-SHA-256/384/512 test vectors
- [FIPS 198-1 - The Keyed-Hash Message Authentication Code (HMAC)](https://csrc.nist.gov/pubs/fips/198-1/final) - NIST standard for HMAC

## Related reading

- [Authenticating API requests with HMAC](https://ronutz.com/en/learn/hmac-api-signing.md): How a shared secret and a hash let a server trust a request it did not see being made, and how replay protection fits in.
- [Hashing, encryption, and encoding: three different things](https://ronutz.com/en/learn/hashing-encryption-encoding.md): Three operations that get constantly confused, separated cleanly by two questions: is it reversible, and does it need a key?
- [HMAC: keyed hashing for message authentication](https://ronutz.com/en/learn/hmac.md): Why a plain hash proves integrity but not authenticity, how a secret key fixes that, and why HMAC's structure matters.
- [Verifying an HMAC safely: constant-time and replay](https://ronutz.com/en/learn/verifying-hmac.md): Why comparing signatures with == leaks a timing side channel, and why a valid signature alone does not stop a replayed request.
- [Why HMAC, and not hash(key + message)](https://ronutz.com/en/learn/why-hmac.md): The length-extension attack that breaks naive keyed hashing, and the nested construction HMAC uses to defeat it.