Contact

Tools  /  Security  /  HMAC Generator

HMAC Generator

Keyed-hash message authentication -- MD5/SHA-1/256/384/512, hex/Base64/Base64url key input, webhook signature formats.

What this tool does

Computes an HMAC (keyed-hash message authentication code) from text or a file, using MD5, SHA-1, SHA-256, SHA-384 or SHA-512 as the underlying hash. Unlike a plain hash, HMAC proves the message came from someone who holds the secret key — this is what powers webhook signature verification (GitHub, Stripe, Shopify, Slack and most other platforms all sign their webhook payloads with HMAC-SHA256), API request signing, and message-integrity checks where a plain hash wouldn't be enough (anyone could recompute a plain hash; only the key holder can recompute the HMAC).

Why the key encoding matters

Different platforms hand out webhook secrets in different forms — a plain UTF-8 string, a hex string, or Base64 — and HMAC treats the key as raw bytes, so decoding it the wrong way produces a completely different (wrong) result even though the key "looks" the same. This tool lets you pick how to interpret the key you paste: UTF-8 text (most common, and what most webhook secrets actually are), hex, or Base64 — get this wrong and every signature will fail to verify, which is one of the most common real-world mistakes when implementing webhook verification from scratch.

Matching real webhook signature formats

Most platforms don't send a bare hex digest — they wrap it in a specific header format. This tool shows your computed HMAC pre-formatted the way the most common platforms actually send it: GitHub's X-Hub-Signature-256 header (sha256=<hex>), a generic Stripe-style format (v1=<hex>, though Stripe's real scheme additionally includes a timestamp in the signed payload — see their docs for the exact construction), and a plain Base64 variant some platforms (including Shopify) use instead of hex — so you can compare your own implementation's output directly against what you'd actually receive in a request header.

Privacy

Every HMAC is computed locally using the Web Crypto API (plus a from-scratch HMAC-MD5 implementation, since Web Crypto doesn't offer MD5). Nothing — key, message, or file contents — is ever sent to a server.

Frequently asked questions

Is my key or message uploaded anywhere?
No. HMAC computation runs entirely in your browser via the Web Crypto API, including file contents — nothing is sent to a server.
Why doesn't my HMAC match what the API/webhook sent?
The most common cause is the key encoding — if the platform gave you a hex or Base64 secret and you enter it as plain text (or vice versa), HMAC treats it as completely different bytes and the result won't match. Double-check which encoding the secret is actually in, and that you're hashing the exact raw request body, not a reformatted or re-serialized copy of it.
What is HMAC actually proving, compared to a plain hash?
A plain hash only proves data hasn't changed -- anyone can compute it. HMAC additionally proves whoever produced it holds the shared secret key, which is what makes it suitable for verifying a webhook or API request actually came from the platform that claims to have sent it.
Which algorithm should I use?
HMAC-SHA256 is the standard choice and what nearly every modern webhook platform uses. HMAC-SHA1 and HMAC-MD5 are kept for compatibility with older or legacy systems; HMAC-SHA384/512 exist for when a longer digest is specifically required.
Can I compute an HMAC over a file instead of text?
Yes -- switch to file input and the HMAC is computed over the file's raw bytes, the same way it would be over a request body.
What do the GitHub/Stripe/Shopify-style formats show?
The exact header format each platform wraps its HMAC digest in, so you can directly compare your computed value against a real request header. Stripe's actual scheme additionally signs a timestamp alongside the payload -- the format shown here is the digest portion only, not the full construction.
Theme Accent