HMAC Generator / Verifier (SHA‑256 / SHA‑512)
Generate HMAC (Hash-based Message Authentication Code) using SHA-256 or SHA-512 algorithms. Verify message authenticity and integrity with shared secret keys. Essential for API authentication, webhook verification, and secure communications.
HMAC Generation Settings
0 characters
Secret key should be cryptographically random. Minimum 32 hex characters (16 bytes) recommended.
HMAC-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))
- • Key requirement: Shared secret key known only to sender and receiver
- • Security: Resistant to length extension and collision attacks
- • Deterministic: Same message and key always produce identical HMAC
- • Hash algorithms: Works with any cryptographic hash (SHA-256, SHA-512)
- • This tool uses the browser's native Web Crypto API for optimal security
HMAC Security Best Practices
⚠️ Security Considerations
Common Use Cases
SHA-256 vs SHA-512 for HMAC
About HMAC Generator / Verifier (SHA‑256 / SHA‑512)
The HMAC Generator & Verifier is a professional cryptographic tool that creates and verifies HMAC (Hash-based Message Authentication Code) signatures using SHA-256 or SHA-512 algorithms. HMAC provides both data integrity verification and authentication by combining a secret key with a cryptographic hash function, ensuring that messages haven't been tampered with and originate from someone possessing the shared secret key.
Why use a HMAC Generator / Verifier (SHA‑256 / SHA‑512)?
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.
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
Input your secret key that will be shared between sender and receiver
Select the hash algorithm (SHA-256 for standard security, SHA-512 for maximum security)
Click generate to create the HMAC signature for message authentication
For verification, enter the message, key, and existing HMAC to confirm authenticity and integrity
Frequently Asked Questions
How do I generate an HMAC and what does it actually do?
Enter the message and the shared secret key, choose the underlying hash (HMAC-SHA256 is the modern default), and the tool outputs the HMAC tag as hex. HMAC (Hash-based Message Authentication Code) combines the key and message in a specific way (key XOR padding then double-hash) to produce a tag that verifies both authenticity (the sender has the key) and integrity (the message wasn't modified). Used in: AWS request signing (SigV4), Stripe / GitHub / Shopify webhook signatures, JWT HS256, OAuth 1.0, TLS, IPsec. The key advantage over a plain hash: an attacker who modifies the message can't forge a valid tag without knowing 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-SHA256 so you can verify they came from the platform); API request signing (AWS SigV4 uses HMAC-SHA256 in a derived-key scheme); session tokens (JWT HS256 = HMAC-SHA256 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?
Match the underlying hash's output size: HMAC-SHA256 keys should be at least 256 bits (32 bytes) of cryptographic random; HMAC-SHA512 keys should be at least 512 bits (64 bytes); HMAC-SHA1 (still secure for HMAC despite SHA-1's other issues) should be 160+ bits. Longer keys don't add security beyond the hash's output size — HMAC internally truncates keys longer than the hash block size. Generate keys using a cryptographic RNG (crypto.getRandomValues, /dev/urandom, openssl rand), never by hashing a passphrase or using Math.random. Store keys in secrets managers (Vault, AWS Secrets Manager) or environment variables — never in source code or logs.
Which HMAC variant should I use in 2026?
HMAC-SHA256 is the modern default and what AWS, Stripe, GitHub, and most major APIs use. HMAC-SHA512 is acceptable and slightly faster on 64-bit platforms (despite the longer output) because SHA-512's internal operations are 64-bit. HMAC-SHA1 is still cryptographically secure (the SHA-1 collision attacks don't apply to HMAC's construction), but you should plan to phase it out — the optics are bad and ecosystem support for SHA-256 is universal. Never use HMAC-MD5 — MD5's weaknesses do partially leak into HMAC-MD5 in some scenarios. The post-quantum hedge is HMAC-SHA3-256, but it's not widely deployed yet.
How do I verify a webhook signature using HMAC?
Extract the signature from the webhook's headers (Stripe uses Stripe-Signature, GitHub uses X-Hub-Signature-256, Shopify uses X-Shopify-Hmac-Sha256). Recompute the HMAC-SHA256 of the raw request body using your shared secret. Compare your computed value to the received signature using a constant-time comparison (crypto.timingSafeEqual in Node, hmac.compare_digest in Python). The raw body matters: parse-and-re-serialize will change whitespace and break the signature. If the values match, the webhook is authentic; if they don't, reject the request (return HTTP 401). Never log the secret, the signature, or the body in plain text — they're equivalent to credentials.
Is online HMAC generation safe for production keys?
Yes for testing and debugging, no for production secrets. This tool computes HMAC entirely in your browser — the key and message never leave your device, never touch a network, never appear in logs (verify in DevTools' Network tab: HMAC computation produces zero requests). However, you should never paste production secrets into any browser-based tool unless you've audited the browser context. For real production webhook signature verification, use your application's HMAC library (Node crypto, Python hmac, etc.) inside the request handler. This tool is appropriate for development debugging, signature troubleshooting, and learning — not for serving production 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 faster (kilobytes per second on a phone vs digital signatures' bytes per second) 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.