HMAC Generator / Verifier (MD5, SHA‑1, SHA‑2, SHA3‑256)
Generate and verify HMAC (Hash-based Message Authentication Code) tags with MD5, SHA-1, SHA-256, SHA-384, SHA-512 or SHA3-256. Decode the secret key as UTF-8 text, hex or base64, and output the tag as hex, base64 or base64url. Runs entirely in your browser — built for API request signing, webhook signature verification and JWT debugging.
HMAC Generation Settings
0 characters — hashed as UTF-8 bytes, exactly as sent over the wire
The key is used literally, byte for byte, as typed — this is what hmac.new(b"secret", …) does in Node, Python, PHP and Go.
Lowercase hexadecimal — what GitHub, Shopify and most webhook signatures carry.
HMAC-SHA-256 Result
HMAC result will appear here
Enter message and secret key, then click "Generate"
✅ Message Authentication Standard
- • Cryptographic authenticity: HMAC provides both integrity and authenticity verification
- • Tamper detection: Any modification to message or key produces completely different HMAC
- • Industry standard: Used in JWT tokens, API authentication, and secure protocols
- • Performance: Fast computation while maintaining strong security guarantees
- • Perfect for: API signatures, webhook verification, secure communications
📊 Technical Specifications
- • Algorithm: Hash-based Message Authentication Code (RFC 2104)
- • Purpose: Verify message integrity and authenticity using shared secret
- • Construction: HMAC(K,m) = H((K ⊕ opad) || H((K ⊕ ipad) || m))
- • Hash algorithms: HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 and HMAC-SHA3-256
- • Key encodings: UTF-8 text, hex or base64 — the key field is decoded to bytes before it is used
- • Output formats: lowercase hex, uppercase hex, standard base64 and URL-safe base64 (RFC 4648 §5)
- • Security: Resistant to length extension and collision attacks
- • Deterministic: Same message and key always produce identical HMAC
- • SHA-1, SHA-256, SHA-384 and SHA-512 use the browser's native Web Crypto API; MD5 and SHA3-256 have no Web Crypto equivalent and are computed by the hash-wasm WebAssembly module, downloaded on first use. Both paths run entirely in this tab.
HMAC Security Best Practices
⚠️ Security Considerations
Common Use Cases
Choosing the hash inside HMAC
About HMAC Generator / Verifier (MD5, SHA‑1, SHA‑2, SHA3‑256)
The HMAC Generator & Verifier creates and checks HMAC (Hash-based Message Authentication Code) tags as defined in RFC 2104, using MD5, SHA-1, SHA-256, SHA-384, SHA-512 or SHA3-256 as the inner hash. HMAC provides both data integrity and authentication by combining a secret key with a cryptographic hash function, proving that a message has not been tampered with and originates from someone holding the shared secret. Because an HMAC key is bytes rather than text, the secret can be decoded as UTF-8 text, hexadecimal or base64, and the resulting tag can be rendered as lowercase hex, uppercase hex, standard base64 or URL-safe base64.
Why use a HMAC Generator / Verifier (MD5, SHA‑1, SHA‑2, SHA3‑256)?
HMAC is essential for secure communications because it provides cryptographic proof that a message is authentic and hasn't been modified in transit. Unlike simple hashing, HMAC requires a secret key, making it impossible for attackers to forge valid signatures without access to the key. This makes HMAC perfect for API authentication, webhook verification, and any scenario where you need to verify both message integrity and sender authenticity. Getting a tag to match a real server also depends on two details most tools hide — how the key is decoded and how the tag is encoded — so both are explicit choices here.
Who is it for?
Critical for API developers implementing secure authentication systems, DevOps engineers setting up webhook endpoints, and software architects building microservices with secure inter-service communication. Essential for payment processing systems, cloud service integrations, and any application requiring message authentication between trusted parties with shared secrets.
How to use the tool
Enter the message or data you want to create an HMAC signature for — it is hashed as UTF-8 bytes, exactly as it would be sent over the wire
Enter the shared secret key, or click the refresh button to generate a cryptographically random 32-byte key
Set Key Encoding to match how your server reads the key: UTF-8 text for a literal secret, hex or base64 for a key that is random bytes shown in that form
Select the hash algorithm — HMAC-SHA-256 is the modern default; MD5, SHA-1, SHA-384, SHA-512 and SHA3-256 are there for the systems that require them
Choose the output format: lowercase hex, uppercase hex, standard base64, or URL-safe base64 for JWT and URL-carried signatures
Click generate to produce the tag, then copy or download it; switching the output format re-renders the same tag without recomputing it
To check an existing signature, switch to Verify mode and paste the message, key and received tag — a GitHub-style sha256= prefix or a Stripe t=…,v1=… header is accepted as pasted
Read the verdict carefully: a mismatch means a real difference in message, key, key encoding or algorithm, while a malformed result means the pasted value is not a tag of that size at all
Frequently Asked Questions
How do I generate an HMAC and what does it actually do?
Enter the message and the shared secret key, tell the tool how to decode the key (UTF-8 text, hex or base64), choose the hash (HMAC-SHA-256 is the modern default) and pick an output format — lowercase hex, uppercase hex, standard base64 or URL-safe base64. HMAC (RFC 2104) combines the key and message as H((K ⊕ opad) || H((K ⊕ ipad) || m)) to produce a tag that proves both authenticity (the sender holds the key) and integrity (the message wasn't modified). Used in AWS SigV4, Stripe / GitHub / Shopify webhook signatures, JWT HS256, OAuth 1.0a, TLS and IPsec. An attacker who edits the message cannot forge a valid tag without the key.
What's the difference between HMAC and a regular hash?
A regular hash (SHA-256, MD5, etc.) takes only a message — it answers 'has this data been changed?' but anyone can compute the hash. HMAC takes a message AND a secret key — it answers 'was this data created by someone who knows the key, and not modified since?'. Without the key, you can't verify or forge an HMAC. This is what makes HMAC useful for API authentication and webhook signatures: the server and client share a secret, the sender includes an HMAC of the request, the receiver recomputes the HMAC with the same secret and compares. If they match, the receiver knows the message is authentic and intact.
When should I use HMAC?
Use HMAC any time you need to authenticate a message between two parties that already share a secret. Concrete examples: webhook signature verification (Stripe, GitHub, Shopify all sign webhook payloads with HMAC-SHA-256 so you can verify they came from the platform); API request signing (AWS SigV4 uses HMAC-SHA-256 in a derived-key scheme); session tokens (JWT HS256 = HMAC-SHA-256 of the token's header and payload); CSRF protection (HMAC of session ID); token derivation (derive multiple per-purpose tokens from a master key). Use it instead of, or in addition to, TLS — HMAC protects message integrity even when TLS is offloaded at a proxy or terminated mid-path.
How long should my HMAC key be, and how is the key field decoded?
Match the underlying hash's output size: at least 256 bits (32 bytes) for HMAC-SHA-256, 512 bits for HMAC-SHA-512, 160+ bits for HMAC-SHA-1. Longer keys add nothing — RFC 2104 hashes any key longer than the block size (64 bytes for MD5/SHA-1/SHA-256, 128 for SHA-384/SHA-512, 136 for SHA3-256) down first. Just as important: an HMAC key is bytes, not text. The 64 characters 'a1b2…' treated as UTF-8 are a 64-byte key; decoded as hex they are a different 32-byte key, and the two produce completely different tags. Set Key Encoding to whatever your server does, and generate keys with a CSPRNG (crypto.getRandomValues, /dev/urandom, openssl rand) — never Math.random or a hashed passphrase.
Which HMAC variant should I use in 2026?
HMAC-SHA-256 is the modern default and what AWS, Stripe, GitHub and most major APIs use. HMAC-SHA-512 and HMAC-SHA-384 are equally sound and are faster than SHA-256 on 64-bit CPUs because SHA-512's internal operations are 64-bit; JWT calls them HS512 and HS384. HMAC-SHA-1 remains cryptographically sound (SHA-1's collision attacks don't break HMAC's construction) but is legacy — AWS SigV2, OAuth 1.0a and TOTP still use it. HMAC-MD5 has no known practical forgery attack either, yet it is deprecated everywhere; both are offered here so you can reproduce and debug signatures from systems you don't control, not as a recommendation. HMAC-SHA3-256 is the sponge-based alternative for environments that mandate SHA-3.
How do I verify a webhook signature using HMAC?
Extract the signature header (GitHub sends X-Hub-Signature-256: sha256=<hex>, Stripe sends Stripe-Signature: t=<ts>,v1=<hex>, Shopify sends a base64 X-Shopify-Hmac-Sha256). Paste it into Verify mode as-is: the algorithm prefix and Stripe's t=…,v1=… wrapper are stripped automatically, and hex, base64 and base64url tags are all recognised. Paste the raw request body byte for byte — parsing and re-serialising JSON changes whitespace and breaks the signature. For Stripe, the signed payload is '<timestamp>.<raw body>', not the body alone. In production, do this inside your request handler with a constant-time comparison (crypto.timingSafeEqual in Node, hmac.compare_digest in Python) and reject with HTTP 401 on failure.
Is online HMAC generation safe for production keys?
Yes for testing and debugging, no for production secrets. Your key and message are never transmitted: SHA-1, SHA-256, SHA-384 and SHA-512 run through the browser's native Web Crypto API, while MD5 and SHA3-256 are computed by the hash-wasm WebAssembly module, which this page downloads from our own server the first time you select one of them. That download is code, not your data — no request ever carries the key, the message or the tag, which you can confirm in DevTools' Network tab. Even so, never paste production secrets into a browser tool you haven't audited. Use this for development debugging, signature troubleshooting and learning; use your application's HMAC library for real traffic.
What's the difference between HMAC and a digital signature?
HMAC uses a shared secret key — both sender and receiver have the same key, so either could create or verify a tag. Digital signatures use asymmetric crypto: the sender signs with a private key, anyone can verify with the public key. HMAC is far faster (it costs about two hash computations, versus a modular exponentiation or elliptic-curve operation) but has weaker non-repudiation: an HMAC tag doesn't prove the sender specifically created it — only that someone with the shared secret did. Use HMAC when you control both endpoints (your API and your client, webhook source and destination). Use digital signatures when verification needs to be public (TLS certs, code signing, signed JWTs distributed across many verifiers).
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.