scriptiii
100% Client-Side

keyed hash · RFC 2104

HMAC generator

Key a message with a shared secret and get the digest in hex and Base64 — checked against an expected value when you paste one.

0 characters

The key and message are read in this tab. Nothing is uploaded, and the key is never written to storage.

Short answer: paste the key, paste the message, read the digest. If the provider gave you a signature, put it in the expected field and the page tells you whether the two agree.

What makes it keyed

HMAC hashes (key ⊕ opad) ‖ H((key ⊕ ipad) ‖ message) — two hashes, so the key is mixed in on both sides and a length-extension attack on the plain hash does not transfer. The construction is defined by RFC 2104 and implemented here by crypto.subtle, not by hand, so there is no bespoke padding code to get wrong.

Verifying webhooks, honestly

A webhook signature covers the raw request body. If you paste JSON that a formatter re-indented, or keys that were reordered, the bytes differ and so does the digest — the signature will look wrong even though nothing was tampered with. Providers that include a timestamp sign timestamp + "." + body; the message field is where that string goes, exactly as the provider documented it.

For an unkeyed digest — a file checksum, a cache key — use thehash generator. For a signed token rather than a bare digest, the JWT encoder wraps this same primitive in the JOSE format.

HMAC questions

How is HMAC different from a plain hash?

A SHA-256 digest of a message can be computed by anyone, so it proves only that the bytes did not change. HMAC mixes a secret into the computation, so only someone holding the key can produce the same value — that is what makes it a signature rather than a checksum.

Which secret should I use?

The one the other side already shares: an API signing key, a webhook secret, a session key. Never invent a short one — an HMAC key shorter than the digest is the weakest part of the exchange, which is why the summary line shows the key length in bytes.

Why are SHA-1 options still offered?

Because real integrations still use HMAC-SHA-1, and a tool that hides the algorithm people need sends them to a worse tool. The page labels SHA-1 as legacy rather than pretending it is a good default; HMAC-SHA-1 is not broken the way plain SHA-1 collisions are, but new systems should use SHA-256.

Can I verify a webhook signature with this?

Yes for the comparison step: paste the signature the provider sent into the expected field and the page says whether it matches. Remember that providers usually sign a specific string — a timestamp plus the raw body — and re-serialising the JSON changes the bytes and therefore the signature.

Is the key sent anywhere?

No. The key is imported with crypto.subtle as a non-extractable CryptoKey for one call and the page makes no network request. Reload the tab and it is gone.

Related tools

Hash generatorMD5, SHA-1, SHA-256 and SHA-512 digests.JWT encoderSign an HS256 token with the same primitive.Base64 encoderEncode the binary digest for a header.JWT decoderInspect the token a signature covers.