HMAC Generator

Signing a Message with a Shared Secret

1. Paste the message you want to authenticate into the message textarea. This is the bytes that will be signed; anything from a JSON webhook body to a Unicode string works.
2. Enter the shared secret in the key input. In production this is typically a 32-byte random value from a CSPRNG encoded as hex or Base64; for testing any string is accepted.
3. Pick the underlying hash: SHA-1 for legacy interop (AWS Signature v2, RFC 2104 test vectors), SHA-256 for almost everything modern (JWT HS256, Stripe webhooks, GitHub webhooks), SHA-384 for higher-security payloads, SHA-512 when you need the longer tag.
4. Click "Generate HMAC". The tool imports the key via crypto.subtle.importKey with the matching algorithm name (HMAC with hash: 'SHA-256'), then calls crypto.subtle.sign on your message bytes.
5. Copy the hex digest and paste it into the X-Signature header (or wherever your API expects it). On the receiving side, the server recomputes HMAC on the same bytes with the same key and compares with a timing-safe equality check.

What HMAC Solves That a Bare Hash Cannot

HMAC (Hash-based Message Authentication Code) is specified in RFC 2104 and FIPS 198-1: HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)) where K' is the key padded to block size, ipad = 0x36 repeated and opad = 0x5C repeated. The double-hash with inner/outer padding defeats length-extension attacks on raw Merkle-Damgard SHA-1/SHA-256. Given bare SHA256(key || msg), an attacker who observes one valid tag can forge a tag for key || msg || padding || evil; HMAC prevents this. The Web Crypto API exposes HMAC through crypto.subtle.sign and crypto.subtle.verify, both implemented natively (BoringSSL for Chromium, NSS for Firefox). The verify path runs in constant time. This tool uses only sign; in production verification code, always use verify rather than comparing hex with ===.

Where HMAC Shows Up in Real Systems

• Webhook signature verification: GitHub signs webhook bodies with HMAC-SHA-256 in the X-Hub-Signature-256 header; Stripe uses Stripe-Signature with HMAC-SHA-256; Slack uses a versioned HMAC-SHA-256 scheme.
• JWT signing for HS256/HS384/HS512 algorithms (RFC 7518), used by Auth0, Clerk, and every library that supports symmetric JWTs.
• AWS Signature Version 4 for all REST API calls: a chain of HMAC-SHA-256 invocations derives per-request, per-region, per-service signing keys from your secret access key.
• TOTP and HOTP one-time password codes (RFC 6238, RFC 4226) compute HMAC-SHA-1 of a time counter and dynamically truncate to 6 digits.
• TLS 1.2 record layer uses HMAC for message integrity inside ciphersuites that are not AEAD (though TLS 1.3 moved entirely to AEAD).
• Signed URLs (S3 presigned URLs, CloudFront signed URLs, custom CDN token auth) embed an HMAC that the server verifies before serving the resource.

The Failure Modes That Actually Cause Outages

The top HMAC implementation bug is non-constant-time comparison. If you compare the received tag to the computed tag with === or ==, the early-exit on first byte mismatch leaks timing information. The fix is crypto.subtle.verify, crypto.timingSafeEqual in Node, hmac.compare_digest in Python. The second is key confusion across algorithms: if your server accepts both HS256 and HS384, an attacker can swap algorithm headers and sign with a longer key. Pin the algorithm server-side. Third, canonicalization: HMAC signs bytes, so sender and receiver must agree on exact bytes. GitHub and Stripe sign raw request bodies; if middleware re-serializes before verification, the tag will not match. Fourth, HMAC keys must be treated like any other secret - a shared key in source code is a plaintext password.

RFC 2104, FIPS 198-1, and Why HMAC Looks Weird

HMAC was designed by Bellare, Canetti, and Krawczyk in 1996 and standardized in RFC 2104 (1997) as the IETF\'s answer to the CBC-MAC pitfalls and the ad-hoc "secret prefix" schemes that preceded it. The inner-outer padding structure ensures HMAC remains a secure MAC even if the underlying hash function has some collision weaknesses: HMAC-MD5 was still secure long after MD5 collisions were found, because collision resistance is not the property HMAC needs from its hash. What HMAC needs is pseudo-random-function behavior, which SHA-1, SHA-256, and SHA-512 all provide. The output size equals the underlying hash output size: 20 bytes for HMAC-SHA-1, 32 bytes for HMAC-SHA-256, 64 bytes for HMAC-SHA-512. Truncation is allowed (RFC 2104 section 5) down to half the hash output - HMAC-SHA-256-128 truncates to 16 bytes and is still secure. The key can be any length; if it is longer than the hash block size (64 bytes for SHA-256, 128 for SHA-512) it is hashed first, so using a 1MB key gains nothing beyond the first block-size-hashed bytes.

HMAC vs Poly1305, KMAC, and Asymmetric Signatures

HMAC is the incumbent; Poly1305 (RFC 8439, ChaCha20-Poly1305 AEAD) is much faster than HMAC-SHA-256 on platforms without SHA-NI and is what TLS 1.3 mobile connections use. KMAC (NIST SP 800-185) is the SHA-3-based alternative, cleaner but not widely deployed. For asymmetric trust where only one party has the signing key, use Ed25519 (RFC 8032) or ECDSA - HMAC requires both parties share the secret. Practical guidance: webhook signatures, JWT HS-prefix, AWS signing, TOTP use HMAC-SHA-256. Tight inner loops use Poly1305. Multi-party trust uses Ed25519. The companion RSA and TOTP tools on this site cover those alternatives.