What is HMAC?

HMAC (Hash-based Message Authentication Code) combines a cryptographic hash function (SHA-256, SHA-512, etc.) with a secret key to verify BOTH the integrity AND authenticity of a message. Unlike a plain hash (which anyone can compute), HMAC requires the secret key — only parties who share the key can generate or verify it. This makes HMAC essential for: API request signing (AWS, Stripe, GitHub use HMAC), webhook verification (proving webhooks came from the claimed source), session tokens (JWT uses HMAC for HS256 signatures), file integrity verification, message authentication in protocols (IPSec, TLS), and any scenario needing ‘this message wasn't tampered with AND came from the right party’.

How to use this tool

1. Enter your message — The data to authenticate. Can be JSON, URL, plain text, anything.
2. Enter the secret key — Shared secret only authorized parties know. Keep this private.
3. Choose algorithm — HMAC-SHA-256 (recommended), SHA-1 (legacy), SHA-384, SHA-512 (stronger).
4. View HMAC output — Hex string — the authentication code.
5. Send message + HMAC — Recipient verifies by computing HMAC with same key — must match.

How HMAC works

Simplified algorithm:

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

Where:
K = secret key
m = message
H = hash function (SHA-256, etc.)
opad = outer padding (0x5C repeated)
ipad = inner padding (0x36 repeated)
K' = key (padded or hashed if too long/short)

Why HMAC, not just hash?

Plain hash H(message): anyone can compute it; if attacker modifies message, they can recompute the hash to match. No authenticity.

HMAC(key, message): only parties with key can compute valid HMAC; modifying message without key produces invalid HMAC; attacker can't recreate.

Algorithm comparison:

• HMAC-SHA-1 (160 bits): Legacy use; still widely deployed (e.g., AWS Signature V2). Don't use for new systems.
• HMAC-SHA-256 (256 bits): Modern standard. Used by JWT (HS256), AWS SigV4, GitHub webhooks. Recommended.
• HMAC-SHA-384 / SHA-512: Higher security for sensitive applications.

Examples

• API request signing: AWS SigV4 uses HMAC-SHA-256 to sign every API request
• Webhook verification: Stripe sends HMAC-SHA-256 signature; you verify with shared key to confirm webhook is real
• JWT (JSON Web Token): HS256 algorithm = HMAC-SHA-256 over header.payload with secret key
• Session integrity: Cookie value + HMAC ensures cookies aren't tampered between sessions
• File checksum with auth: Distribute software with HMAC; verify download didn't come from rogue mirror
• Telegram bot security: Bot updates signed with HMAC; bot verifies before processing

Tips & best practices

• Use HMAC-SHA-256 for new systems — modern standard, widely supported
• Keep secret key TRULY secret — treat like password
• Use long random keys (32+ bytes) for HMAC-SHA-256 — same length as hash output
• Don't reuse same key across services — key compromise affects everything
• For webhook verification, compute HMAC of received body; constant-time compare with sender's HMAC
• Rotate keys periodically — replace compromised keys without breaking system
• Use libraries (crypto.subtle in browser, hmac in Python, jsonwebtoken in Node) — don't implement from scratch

Limitations & notes

HMAC only authenticates — doesn't encrypt. Message contents are still visible. For confidentiality + integrity, combine with encryption (AES + HMAC, or use AEAD modes like AES-GCM). HMAC security depends on key secrecy — if key leaks, system is compromised. SHA-1 HMAC still considered safe in HMAC context (collision attacks don't apply), but better to use SHA-256 for new systems.

Frequently Asked Questions

What's the difference between HMAC and just hashing?

Plain hash (SHA-256 of message): anyone can compute; offers integrity but no authenticity. HMAC requires a secret key — provides both integrity AND authenticity. Only parties knowing the key can generate or verify.

Is HMAC-SHA-1 still safe?

Yes in HMAC context — the collision attacks against SHA-1 don't apply to HMAC. AWS still uses HMAC-SHA-1 for SigV2. However, for new systems, use HMAC-SHA-256 — widely supported, future-proof.

How long should my secret key be?

For HMAC-SHA-256, use 32 bytes (256 bits) of random key. Shorter keys reduce security; longer keys offer minimal additional security but don't hurt.

How do I verify a received HMAC?

Compute HMAC of message with same secret key, compare to received HMAC. Use CONSTANT-TIME comparison (e.g., crypto.timingSafeEqual in Node) to prevent timing attacks.

Can HMAC be reversed?

No — HMAC is one-way. Given HMAC output, you cannot derive the original message or key. Same input always produces same output, but you can't go backward.

What's a timing attack?

Comparing HMAC values with regular string comparison (==) reveals timing differences character-by-character. Attackers exploit this to guess HMAC byte-by-byte. Use constant-time comparison functions.

Does HMAC encrypt my message?

No — HMAC only authenticates. Message remains visible. For confidentiality, encrypt separately (AES) and authenticate the encrypted data with HMAC, or use authenticated encryption (AES-GCM, ChaCha20-Poly1305).

Related tools

Hash Generator · Bcrypt Generator · JWT Decoder