HMAC Generator
Generate and verify HMAC signatures using HMAC-SHA256, SHA-512, SHA-384, or SHA-1. Uses the native Web Crypto API — nothing leaves your browser.
🔐 Web Crypto API
Uses the browser's native SubtleCrypto API for cryptographically correct HMAC computation. No external libraries.
🔒 100% Private
Your message and secret key never leave your browser. No server requests, no logging, no storage.
✅ Verify Mode
Paste an existing HMAC to verify it matches the computed value — useful for debugging webhook signatures.
Frequently Asked Questions
What is HMAC?
HMAC (Hash-based Message Authentication Code) combines a secret key with a hash function (like SHA-256) to produce a fixed-length signature. Unlike a plain hash, HMAC requires knowing the secret key to verify the signature — which is what makes it useful for authentication.
What is HMAC used for in practice?
HMAC is the backbone of many security systems: Stripe, GitHub, and Shopify use HMAC-SHA256 to sign webhook payloads so you can verify the request came from them. AWS uses HMAC for its Signature V4 request signing. JWTs signed with HS256 use HMAC-SHA256. API keys are often HMAC-based.
HMAC-SHA256 vs HMAC-SHA512 — which should I use?
HMAC-SHA256 (32-byte output) is the standard choice and is universally supported. HMAC-SHA512 produces a 64-byte output and is marginally stronger, but SHA-256 is considered secure for all practical purposes. Use HMAC-SHA256 unless your specific protocol requires something else.
How is HMAC different from a plain hash?
A plain hash (like SHA-256) of a message always produces the same output — anyone who knows the algorithm can compute it. HMAC requires a secret key, so only parties who know the key can generate or verify the signature. This makes HMAC suitable for authentication, where a plain hash would not be.
Does HMAC encrypt my message?
No. HMAC authenticates a message but does not conceal it — the message travels in plaintext and only the signature is computed. If you also need confidentiality, encrypt the message and sign the ciphertext (the standard encrypted-then-MAC pattern).
Why does my webhook signature not match?
The most common causes are mismatched output encoding (hex versus base64), signing a subtly different body (for example, with or without a trailing newline), or feeding the wrong value into the tool. Sign the exact raw bytes the provider describes and use the encoding the provider expects.
What length should my secret key be?
HMAC accepts any key length, but you should use at least 32 random bytes for HMAC-SHA256 and 64 for HMAC-SHA512. Keys longer than the hash function's block size are internally hashed, so extremely long keys add no extra security.
How to Generate an HMAC Signature
HMAC (Hash-based Message Authentication Code) takes two inputs — a message and a secret key — and produces a fixed-length signature. The signature is computed in your browser with the native Web Crypto API, so neither your message nor your key is ever transmitted. You can use it freely with real API secrets.
- Enter the message you want to sign — for example, the raw body of a webhook payload you are sending or receiving.
- Enter your secret key. Both parties must share the exact same key. Store it in a password manager or environment variable, never in source code.
- Pick an algorithm. HMAC-SHA256 is the default for most platforms including Stripe, GitHub, and Shopify. Choose SHA-512 when the receiving system specifies it.
- Choose the output format. Hexadecimal is the most common on the web. Use base64url when the receiving system expects it — for example, JWT HS256 signatures are always base64url.
- Copy the signature and, when testing webhooks, paste it into the Verify field on this page to confirm your message and key produce exactly that value before you debug higher up the stack.
Real-World HMAC Use Cases and Common Mistakes
HMAC is everywhere in modern infrastructure. When Stripe, GitHub, or Shopify sends a webhook to your server, each request carries an X-...-Signature header that is an HMAC-SHA256 of the payload signed with a secret you configured in the dashboard. Your server recomputes the signature and compares — if it matches, the payload is both authentic and unmodified. AWS uses the same idea in Signature V4 across all of its API requests, and JWT tokens signed with the HS256 or HS384 algorithms are plain HMACs of their header and payload.
Because HMAC verification is a simple string comparison, most integration bugs live in the details. These are the mistakes that come up again and again:
- Hex vs. base64 mismatch. Both encodings represent the same bytes. If the provider sends hexadecimal and you compare against base64, the signatures never match.
- Signing the wrong body. Webhook frameworks often reformat the request body — a trailing newline changes every byte. Compute the HMAC over the exact raw body, byte for byte, as the provider describes.
- Forgetting the timestamp. Many providers sign a string that includes the timestamp, then expire signatures older than a few minutes. Reuse the exact same string in your recomputation.
- Comparing with == instead of a constant-time comparison. Use
crypto.timingSafeEqual(or the equivalent in your language) to avoid timing attacks.