HMAC Generator

Compute HMAC-SHA-256, HMAC-SHA-1 or HMAC-SHA-512 with your key right in the browser. HEX and Base64 output, reference comparison and test vectors included.

Everything runs in your browser — your data is never sent to any server.

Why compute an HMAC

HMAC is a message signature computed with a secret key, and you need it every time services exchange requests and someone has to prove the data was not altered in transit. API request signing, webhook verification from payment providers, JWT tokens with the HS256 algorithm — inside all of them sits exactly HMAC, most often with SHA-256. The generator takes a message and a key, lets you pick the hash function, and produces the signature in both HEX and Base64, plus lets you compare the result against a reference value. Everything runs through Web Crypto in your browser, and the key never leaves your machine.

What the generator offers

Computes HMAC-SHA-1, HMAC-SHA-256 and HMAC-SHA-512 through crypto.subtle.sign
Accepts any message and a key of any length, including empty text
Shows the signature in two formats at once: HEX and Base64
Compares the result with a reference signature and tells you whether it matched
Fills in the classic fox-sentence example — the answer is easy to verify

How to compute the signature

Paste the message: a request body, a webhook string, any text
Enter the secret key — the same one the other side uses
Pick the hash function: SHA-256 remains the default choice
Press the button and copy the HEX or Base64, comparing against a reference if you have one

How HMAC is built

Simply gluing a key onto a message before hashing is unsafe, so HMAC is built on two passes. The key is first brought up to the hash function's block size: 64 bytes for SHA-256, 128 for SHA-512; an overly long key is hashed first. Then two derived sequences are prepared: the inner one — the key XORed with the ipad constant 0x36 — and the outer one — the key with the opad constant 0x5C. The signature is computed as the outer hash of the inner hash of the message: H(opad-key || H(ipad-key || message)). The scheme was invented in 1996 by Bellare, Canetti and Krawczyk, described in RFC 2104, standardized in FIPS 198-1, and no practical attack on it has been found in the decades since.

Test vectors: signatures for the classic example

Algorithm	Signature in HEX	Length
HMAC-SHA-1	de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9	40 hex chars, 160 bits
HMAC-SHA-256	f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8	64 hex chars, 256 bits
HMAC-SHA-512	b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a	128 hex chars, 512 bits
HMAC-SHA-256 in Base64	97yD9DBThCSxMpjmqm+xQ+9NWaFJRhdZl0edvC0aPNg=	the same signature in another format
RFC 4231, test 2	5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843	key Jefe, message what do ya want for nothing?
Another key	e21d6984a9ea09770d8df6eee046f3c2f85463f4daad128d4409a39fce912ee0	same message, key another — the signature changes entirely
Another text	e98139c39d76eb80d8db982552b44b251b94f312987f91ee72d12ef673caa813	one period added at the end, the signature changed completely
Empty message	a signature is computed for an empty string too	the message may be of zero length

For rows 1–4 the message is "The quick brown fox jumps over the lazy dog" and the key is "key". The values are one line to verify in any language.

Where you meet HMAC every day

Webhooks are the closest example for a developer. A payment system sends an event to your endpoint and attaches a signature of the request body; the receiver recomputes the HMAC with the same secret and compares. Signature matched — the event really came from the payment system and was not altered on the way. Not matched — the request is dropped, because either it is a forgery or your secret has drifted from the sender's. Without this check anyone who learns the webhook URL could send you fake payments.

The second large zone is API request signing. The client builds a string from the method, path, headers and timestamp, signs it with the shared secret and sends it along with the signature; the server repeats the same computation and compares. The timestamp in the string protects old requests from being replayed hours later. JWT tokens with HS256 and one-time two-factor codes are the same HMAC wrapped in another format. How plain keyless hashes work — the natural comparison point — is covered in the multi-hash generator.

Verifying webhooks from payment systems and notification services
API request signing: method, path, headers and timestamp in one string
JWT tokens with the HS256 algorithm
One-time codes in two-factor authentication
Exchange between your own services, where public keys are overkill

Typical mistakes when working with HMAC

The first mistake is a format drift between the two sides. The sender signs the raw request body, the receiver pretty-prints the JSON first and signs the formatted string with spaces — the signatures will not match even though the content is identical. Encodings belong here too: Cyrillic in UTF-8 produces different bytes than in Windows-1251. One rule: sign exactly the byte sequence that travels over the wire, and agree on it in advance on both sides.

The second mistake is the key in logs. While debugging a mismatch, a developer prints the key and the message to a log, and the logs later leak together with backups and contractor access. A signature without the secret is worthless, so the log gets the message and the signature but never the key. The third mistake is keeping one key forever: keys are rotated on schedule and replaced immediately on compromise, because old signatures stop being proof.

Sign the exact bytes of the message, no reformatting
Different Cyrillic encodings produce different signatures
The key is never logged and never pasted into tickets
Sender and receiver must use the same algorithm
Server-side comparison uses constant time
Keys are rotated, not used for decades

Worked example: the computation step by step

Take the classic pair: the fox message and the key "key". Step one is bringing the key to block size: the three-byte string is padded with zeros to 64 bytes for SHA-256. Step two produces the inner and outer key variants: one copy is XORed with the constant 0x36, the other with 0x5C. Step three is the inner hash: SHA-256 of the ipad-key joined with the message, giving 32 bytes. Step four is the outer hash: SHA-256 of the opad-key joined with those 32 bytes. The result starts with f7bc83f4... and that is exactly what the generator shows.

You can verify the result three ways: the example button in the generator itself, a single line in any programming language, or comparison with the vectors in standard RFC 4231. If a signature does not match, check the algorithm first, then the exact message text — an extra space or a trailing newline changes all 64 hex characters. The vector summary is below.

What happens at each step

Step	Action	Result
1	Key brought to block size	64 bytes for SHA-256, the rest padded with zeros
2	Two key variants	XOR with ipad 0x36 and with opad 0x5C
3	Inner hash	SHA-256 of ipad-key plus message, 32 bytes
4	Outer hash	SHA-256 of opad-key plus the inner hash
5	Finished signature	32 bytes, or 64 hex characters for SHA-256
6	Transport	the signature travels beside the message, in a header or body
7	Verification	the receiver repeats steps 1–4 and compares
8	Mismatch	one differing byte — the whole signature is different

The hash function sets the block size and the signature size: SHA-1 yields 20 bytes, SHA-256 32, SHA-512 64 — the mechanism itself stays the same.

What pairs well with HMAC work

HMAC rests on plain hashes, and understanding them on their own helps: what the hash length gives you, why MD5 no longer protects against forgery, what collisions look like. All of that is covered in the article on MD5 and SHA-256 hashes, while computing keyless hashes is available in the multi-hash generator or the dedicated SHA-256 generator. If the signature is needed for a token, look at the JWT generator — there HMAC-SHA-256 is packed into the three-part format with a header and a payload.

For real systems, keys are made as long random strings and kept in a secrets manager rather than in a repository. Webhook verification is written with the constant-time comparison function the language's standard library provides. And keep the simple picture in mind: HMAC answers the question "did this message come from someone who knows the secret, and did it change on the way" — no more, no less. It does not encrypt the content and it does not prove the sender's identity beyond knowledge of the key.

Keyless hashes — integrity; HMAC — authenticity
RFC 2104 describes the scheme, RFC 4231 provides test vectors
The key lives in a secrets manager, not in code
JWT HS256 and TOTP codes are HMAC in another wrapper
Verification without a shared secret calls for asymmetric signatures

Frequently asked questions

How does HMAC differ from a plain hash

By the key. Anyone can compute a plain SHA-256 of a text, so altering a message together with its hash costs nothing: re-read the data, recompute, substitute. HMAC adds a secret known only to the sender and the receiver, so a forged signature is useless: without the key, no valid signature for a new message can be built. That is why checking the integrity of a downloaded file needs only a plain hash, while checking the authenticity of a message needs exactly HMAC.

Why not just append the key to the message

The scheme of hashing key-plus-message is vulnerable to the length extension attack: having seen one signature, an attacker can append data to the message and continue the computation to a valid signature without knowing the key, because the internal hash state carries over. The message-plus-key arrangement has its own weaknesses. HMAC solves the problem with two nested hashes over different constants: only the outer pass is visible, and the inner state stays out of reach. That is why a separate standard exists, although at first glance a keyed hash looks easy to build yourself.

Which algorithm to choose: SHA-1, SHA-256 or SHA-512

SHA-256 is the safe default: request-signing specifications at major cloud providers and most webhook services demand it. HMAC with SHA-1 has not been broken the way SHA-1 itself broke for collisions, but new systems do not start with it: the standard survives in legacy integrations and some two-factor code schemes. SHA-512 gives a 512-bit signature and runs faster on 64-bit processors for large volumes. The crucial part: both sides must use the same algorithm, otherwise verification fails every time.

Where is HMAC used in practice

API request signing: major cloud providers sign a string of method, path, parameters and timestamp with every request. Webhooks: payment systems and notification services send a signature of the payload along with the event, and the receiver recomputes the HMAC before trusting the data. JWT tokens with the HS256 algorithm are HMAC-SHA-256 over two token parts, visible in action in the JWT generator. One-time two-factor authentication codes are built on HMAC as well. The list keeps growing: wherever two parties need to trust data without public keys.

What is the fox example and can it be trusted

It is the classic verification pair: the message "The quick brown fox jumps over the lazy dog" with the key "key". HMAC-SHA-256 of it gives f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8, HMAC-SHA-1 gives de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9, and HMAC-SHA-512 gives b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a. The trio is one line to reproduce in any language, which is why it became the standard sanity check: if your tool produces these values, it computes HMAC correctly.

What key length is needed

A short key cancels the protection: brute-forcing eight characters takes seconds, and then the whole signature mechanism is pointless. Working practice is a random string from 32 bytes, roughly 256 bits of entropy; keys longer than the hash block are also accepted by the standard, hashed down first. More important than length: the key must be random and stay secret. Generate one with the password generator, and the requirements for a strong string are covered in the article on a strong password.

What is constant-time comparison for

If the server compares signatures character by character and responds at the first mismatch, the response time leaks how many leading characters matched. That lets an attacker assemble a signature piece by piece. Constant-time comparison walks the whole string regardless of where the first difference is, and the response time stops telling anything. The browser generator uses an ordinary comparison — indifferent for tests — but in server code, especially webhook verification, the constant-time function comes from the language's standard library.

How does HMAC-SHA-256 differ from other signing methods

By symmetry. HMAC has one shared secret: whoever holds the key can sign and verify, so the scheme fits when both sides already trust each other and only need a tamper-proof channel. Asymmetric signatures like RSA and ECDSA use a key pair: the private one signs, the public one verifies, and the public half can be shown to the world. The rule of thumb: webhook and API signatures between your own services — HMAC; documents and payments where the signature must be verifiable without the author's secret — asymmetric schemes. For plain keyless hashes and their differences there is the article on MD5 and SHA-256 hashes.

HMAC Request Signing: Why APIs Sign Requests and How the Signature Is Computed

Why API requests and webhooks carry an HMAC signature, how HMAC works in plain words, why a signature is not encryption, timing-safe comparison, JWT HS256, and a step-by-step HMAC-SHA-256 calculation with a verified test vector.

HS256 vs RS256: Which JWT Signature to Choose

What HS256 and RS256 actually are, when a shared secret is enough, when an RSA key pair becomes necessary, signature sizes and speed compared, how the algorithm confusion attack works, and how to verify a token under both algorithms in practice.