Generate and verify HMAC signatures using SHA-256, SHA-384 or SHA-512. Perfect for webhook verification, API authentication, and debugging signed requests. All crypto runs in your browser.
Paste an existing signature to compare it against the computed HMAC above.
This HMAC generator computes a keyed message authentication code for any text or payload, combining your secret key with the message under HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512 and showing the result as hex, Base64, or Base64-URL.
HMAC stands for Hash-based Message Authentication Code. Unlike a plain hash, it folds a shared secret into the hashing process, so the signature it produces proves two things at once: that the message has not been altered, and that whoever created it knows the secret key. That combination is why HMAC underpins so much of modern web security — it is how services confirm an incoming request really came from a trusted party and was not forged or tampered with along the way. The signature here is computed entirely with your browser's built-in Web Crypto API, the same audited cryptographic engine that powers HTTPS, so the output matches exactly what your server-side libraries produce for the same key, message, and algorithm. You can also paste a signature you received and use the Verify box to confirm, in constant context, whether it matches the one this tool computes. People use it to:
Everything runs locally through Web Crypto — your secret key and message are never uploaded, logged, or stored, and nothing leaves your device. Because the same key both signs and verifies, treat any production signing secret with care: paste it here only when you trust the machine you are on, and prefer test keys for casual experiments. A matching signature confirms a message is authentic and intact; it says nothing about what the message contains, so always pair HMAC verification with your usual payload validation.
HMAC proves a message was authored by someone holding the shared secret and that it wasn't tampered with in transit. Stripe, GitHub, Shopify, and most webhook providers use it.
Stripe uses hex. GitHub uses hex with a sha256= prefix. AWS Sig v4 uses hex. JWT-style services use Base64-URL. Always check your provider's docs — the byte content is identical, just encoded differently.
No. Signing happens entirely inside the browser via the Web Crypto API. Nothing is uploaded, logged, or stored.
A plain hash like SHA-256 turns any input into a fixed-length fingerprint, but anyone can compute it, so it proves nothing about who created the message. HMAC mixes a secret key into the hashing process, so only parties who know the same key can produce or reproduce a valid signature. That is what makes HMAC a message authentication code: it confirms both integrity (the message was not altered) and authenticity (it came from a holder of the secret), whereas a bare hash only confirms integrity.
The secret key is the shared piece of information that both the sender and verifier know but an attacker does not. Because the same key both signs and verifies, anyone who has it can forge signatures, so it must stay private. For real systems use a long, random key — typically 32 bytes or more — and never embed it in client-side code or commit it to a repository. When you verify a webhook, the key here is the signing secret your provider gives you in their dashboard.
It depends entirely on what the receiving system expects, because the underlying signature bytes are identical. Hex prints each byte as two characters and is the most common format for webhooks like Stripe and GitHub. Base64 is more compact, and Base64-URL is a variant safe to place in URLs and JWTs because it avoids the + and / characters. Pick the encoding your provider documents; if a comparison fails, a mismatched encoding is a frequent cause.
Choose the algorithm your provider uses, usually HMAC-SHA256, then paste the exact raw request body as the message and your signing secret as the key. The tool computes the expected signature. Paste the signature from the incoming request's header into the Verify box and it tells you whether they match. The most common pitfall is that the message must be the byte-for-byte raw payload, before any JSON re-serialisation, or the signatures will not line up.