HMAC Generator & Verifier

Compute HMAC digests using any secret key with HMAC-SHA256, HMAC-SHA1, HMAC-MD5, HMAC-SHA384, and HMAC-SHA512. Verify API request signatures and JWT tokens. All computation in-browser via Web Crypto API — your key and data never leave your device.

Quick load:
🔐 Input
🔑 HMAC Digests
HMAC-MD5
HMAC-SHA1
HMAC-SHA256

Verify HMAC

How HMAC Works

HMAC (Hash-based Message Authentication Code) is defined in RFC 2104 and RFC 4231 (for SHA-2 variants). It combines a secret key with a hash function to produce a message authentication code that verifies both data integrity and authenticity.

Key insight: Unlike a plain hash, HMAC requires a secret key. An attacker who sees the HMAC output cannot forge a valid HMAC for a different message without knowing the key. This is why HMAC is used for API request signing, JWT tokens, and protocol authentication.

HMAC Algorithm (RFC 2104)

HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))

Where:
  K' = key padded to block size (64 bytes for MD5/SHA-1/SHA-256, 128 for SHA-384/512)
  ipad = 0x36 repeated to block size
  opad = 0x5C repeated to block size
  H  = the underlying hash function
  || = concatenation
  ⊕ = XOR

Common Use Cases

Use CaseAlgorithmNotes
API request signing (Stripe, GitHub, Slack)HMAC-SHA256Key is the webhook secret; message is the request body or timestamp + body
JWT HS256/HS384/HS512 tokensHMAC-SHA256/384/512Key is the JWT secret; message is header.payload (Base64url of header + "." + payload)
AWS Signature Version 4HMAC-SHA256Multiple rounds: date key → region key → service key → signing key → signature
OAuth 1.0a signatureHMAC-SHA1Key = consumer_secret & token_secret; message = base string
Webhook verificationHMAC-SHA256Compare X-Hub-Signature-256: sha256=<hex>
HOTP / TOTP (RFC 4226/6238)HMAC-SHA1 or HMAC-SHA256Key = Base32-decoded secret; message = counter (8 bytes BE) or timestamp
IPsec / TLS PRFHMAC-SHA256Used in key derivation and pseudo-random functions

Security Recommendations

Use SHA-256 or stronger: HMAC-MD5 and HMAC-SHA1 are still safe within HMAC (the key prevents collision attacks), but SHA-256 is the modern default for new systems.
Key length matters: Keys shorter than the hash block size are zero-padded; keys longer are hashed first. A 256-bit (32-byte) random key is recommended for HMAC-SHA256.
Timing-safe comparison: When verifying HMAC, always use constant-time comparison to prevent timing side-channel attacks. Never use === in production.
Never reuse keys: Each service should use a unique HMAC key. Compromising one key should not affect other systems.
Deprecation note: While HMAC-MD5 is not broken in the HMAC construction (RFC 6151), it is deprecated for new applications. Use HMAC-SHA256 as the minimum for new designs.

HMAC vs Plain Hash — When to Use Which

NeedUseExample
Verify data integrity (no key)Plain hash (SHA-256)File checksums, software download verification
Verify data authenticity (with key)HMAC-SHA256API signatures, webhook verification, JWT
Derive keys from a master keyHMAC-based HKDF (RFC 5869)TLS key derivation, EAP key hierarchy
Compute CMAC (block cipher MAC)AES-CMAC (NIST SP 800-38B)EMV ARQC/ARPC, GP SCP03 MAC
Related tools: Hash Digest for plain MD5/SHA/SM3 hashes, Crypto Checksum Verifier for CRC/LRC/CMAC, JWT Decoder for inspecting HMAC-signed tokens.

Related Tools