How do I generate an HMAC for a message?
Paste your message, type the shared secret key, and pick a hash (SHA-256 by default). This tool computes the HMAC with the browser WebCrypto API and shows it in hex and base64. Change the message, key or algorithm and the result updates instantly. Everything runs in your browser and nothing is uploaded.
What an HMAC is
An HMAC is a keyed hash: a fixed-length fingerprint of a message that also depends on a secret key. Feed in the same message and the same key and you always get the same value back. Change one character of either and the whole thing changes completely. The name stands for hash-based message authentication code, and it is defined in RFC 2104.
The point of the key is trust. A plain hash such as SHA-256 depends only on the message, so anyone can recompute it, which means it proves nothing about who produced it. An HMAC folds a shared secret into the calculation, so only a party who holds that secret can produce a value that checks out. That lets the receiver confirm two things at once: the message has not been altered, and it came from someone who knows the key.
HMAC versus a plain hash
Think of a plain hash as a tamper-evident seal that anyone can make, and an HMAC as one that only you and the other side can make because you both hold the same stamp. If an attacker changes the message, they cannot produce a matching HMAC without the key, so the check fails. This is why HMAC is used to authenticate messages while plain hashes are used for things like checksums and deduplication.
That value is test case 2 from RFC 4231, the official set of HMAC test vectors. Because HMAC is deterministic you can paste the same key and message above and get exactly the same hex, which is precisely how a server on the other end checks that your signature is genuine.
Where HMAC is used
The most common job is signing API requests. Many services (including the big cloud providers) ask you to build a string from the request details, compute an HMAC of it with your secret key, and send that alongside the request. The server repeats the calculation with its copy of the key: if the two HMACs match, the request is accepted, and because the secret never travels over the wire it cannot be captured in transit.
The second common job is verifying webhooks. When a provider such as a payment platform calls your server, it includes a signature header that is an HMAC of the payload. You compute the same HMAC over the body you received using the signing secret you were given, and only trust the webhook if the two agree. That stops anyone forging events by simply posting to your endpoint. HMAC also sits inside larger schemes: the HS256 option in JWT is HMAC-SHA-256, and key-derivation functions such as HKDF and PBKDF2 are built on it.
Keep the secret secret
The security of an HMAC rests entirely on the key staying private. Anyone who learns it can forge a valid HMAC for any message they like, so treat the key like a password: make it long and random, store it in a secrets manager or environment variable rather than in code, and rotate it if you suspect it has leaked. The choice of hash matters less; SHA-256 is a fine default and SHA-512 is also good. HMAC-SHA-1 is still safe in practice and is only offered here for older systems that require it, but there is no reason to pick it for something new.
This tool computes everything in your browser with the built-in WebCrypto API, so your message, your key and the result never leave your device. That makes it safe to try with real values, though on a shared or public computer you should still clear the fields when you are done.
How we work it out
HMAC as defined in RFC 2104: the secret key and message are combined with a cryptographic hash (SHA-256, SHA-1 or SHA-512) via WebCrypto importKey and sign. The output is shown as lowercase hex and as base64. UTF-8 encoding is used for both the key and the message.
Frequently asked questions
What is the difference between an HMAC and a plain hash?
A plain hash like SHA-256 only depends on the message, so anyone can recompute it. An HMAC also mixes in a secret key, so only someone who knows the key can produce or check the value. That is what lets it prove a message came from a party who holds the shared secret and was not altered on the way.
Which algorithm should I choose?
SHA-256 is the sensible default and is used by most APIs. SHA-512 produces a longer output and is also fine. SHA-1 is offered because some older systems still require HMAC-SHA-1, and HMAC-SHA-1 is not broken in the way plain SHA-1 is, but prefer SHA-256 for anything new.
Is my message or key sent anywhere?
No. The HMAC is computed entirely in your browser using the built-in WebCrypto API. Your message, your secret key and the result never leave your device, so it is safe to use with real values while you test.
Why does the same message give the same HMAC every time?
Unlike encryption, an HMAC is deterministic: the same message and the same key always produce the same value. That is the point, because it lets the other side recompute the HMAC and check it matches. Only the secret key is meant to be private, not the output.
What is HMAC used for?
It signs API requests so a server can confirm the caller holds the shared secret, and it verifies webhooks by checking the signature a provider sends against one you compute yourself. It is also used inside larger schemes such as JWT (the HS256 algorithm) and key derivation.