Question 1

What is HMAC and how does it differ from a regular hash?

Accepted Answer

HMAC (Hash-based Message Authentication Code) is a construction that combines a cryptographic hash function (SHA-256, SHA-512, etc.) with a secret key to produce a fixed-size signature. The difference from a plain hash: a plain hash takes only the message, so anyone can compute or verify it; HMAC takes the message AND a secret, so only parties holding the secret can produce a valid signature. This makes HMAC suitable for AUTHENTICATING that a message came from someone who knew the secret (webhook senders, signed API requests) rather than just verifying integrity. HMAC is defined in RFC 2104 (1997) and is the standard primitive for keyed message authentication across virtually every modern API.

Question 2

Which algorithm should I use?

Accepted Answer

HMAC-SHA-256 is the modern default — it is what AWS Sig V4, GitHub webhooks, Stripe, and JWT HS256 all use. It provides 256-bit output with 128 bits of effective security (collision resistance), which exceeds requirements for any practical use case. Use HMAC-SHA-384 or HMAC-SHA-512 when a specific protocol requires them (e.g. JWT HS384/HS512, TLS 1.3 cipher suites). Avoid HMAC-SHA-1 for new code — although HMAC-SHA-1 is not broken (the collision attacks against plain SHA-1 do not extend to HMAC), best practice is to default to SHA-2 family hashes. Use HMAC-SHA-1 only when a legacy protocol (TOTP per RFC 6238, OAuth 1.0a) explicitly requires it.

Question 3

How long should my secret key be?

Accepted Answer

At minimum, as long as the underlying hash output: 16 bytes (128 bits) for SHA-256, 32 bytes (256 bits) for SHA-256 for best security, 48 bytes for SHA-384, 64 bytes for SHA-512. Shorter keys are still allowed by RFC 2104 but reduce effective security. Our tool warns when your key is shorter than the hash output. For production use: generate keys via crypto.randomBytes(32) (Node.js) or `openssl rand -hex 32` and store them in a secret manager — never hard-code keys in source files.

Question 4

How does this differ from your Hash Generator?

Accepted Answer

Hash Generator computes one-way digests (MD5, SHA-1, SHA-256, SHA-512) from a single message — no key. Use it for content fingerprinting, file deduplication, or generic non-secret integrity checks. HMAC Generator takes BOTH a message AND a secret key; the same message with different keys produces different signatures. Use HMAC for authentication (proving the sender knew the secret) and tamper detection in the presence of an adversary. They solve related but distinct problems.

Question 5

Why are there three output formats?

Accepted Answer

Different protocols expect different encodings of the same bytes. Hex (lowercase, two characters per byte) is the standard for AWS Signature V4 and most signing protocols. Base64 (RFC 4648 standard alphabet) is what PHP, Java, and many web APIs use. Base64URL (Base64 with - and _ replacing + and /, no padding) is used in JWT signatures, OAuth, and other URL-embedded contexts. The three encode identical bytes — pick the one your downstream system expects.

Question 6

Does HMAC prevent replay attacks?

Accepted Answer

No. HMAC verifies that the message came from someone with the secret, but a captured signed request can be re-sent verbatim. To prevent replay, always include a TIMESTAMP and a NONCE (unique-once value) in the signed payload, then reject requests with timestamps outside a short window (5-15 minutes is typical) or with already-seen nonces. AWS Sig V4 includes an X-Amz-Date header in its canonical request; GitHub includes X-GitHub-Delivery for nonce semantics. Always sign these along with the body.

Question 7

How do I verify an HMAC signature on the server side?

Accepted Answer

Compute the expected HMAC on your end (using the same message body, key, and algorithm) and compare to the received signature. Critically, the comparison MUST be constant-time to prevent timing-attack key recovery. Use crypto.timingSafeEqual (Node.js), hmac.compare_digest (Python), or hash_equals (PHP) instead of naive == comparison. A naive comparison leaks one byte of information per failed attempt about how many leading bytes matched — an attacker can extract the correct signature byte by byte.

Question 8

Can I use this for password hashing?

Accepted Answer

No — HMAC is not designed for password storage. Use bcrypt, scrypt, Argon2, or PBKDF2 for passwords. These algorithms are intentionally slow and memory-hard to resist brute-force attacks. HMAC is fast (designed for speed in signing) which makes it terrible for password hashing — an attacker who steals your database can brute-force passwords at billions per second on a GPU. The conceptual confusion arises because PBKDF2 internally uses HMAC as its pseudo-random function — but PBKDF2 iterates it 100,000+ times. Use the right tool: HMAC for signing, dedicated password hashes for passwords.

Question 9

Is my data sent to any server?

Accepted Answer

No. All HMAC computation happens via the browser's built-in Web Crypto API (crypto.subtle.importKey + crypto.subtle.sign). There is no fetch, no XHR, no analytics event with input data. Verify by opening DevTools → Network and computing a hash — observe that no requests are made. Secret keys are some of the most sensitive data developers handle; we treat them accordingly.

Aspect	Plain Hash (SHA-256, MD5)	HMAC (HMAC-SHA-256, etc.)
Inputs	One: the message	Two: message + secret key
Purpose	Detect accidental corruption; one-way mapping	Detect tampering by attackers; authenticate sender
Security model	No secret — anyone can compute and verify	Verifier needs the secret; attackers without it cannot forge
Output length	Same as underlying hash (e.g. 256 bits for SHA-256)	Same as underlying hash
Replay protection	None inherent	None inherent — include timestamp + nonce in the signed payload
Length-extension	SHA-1, SHA-2 vulnerable when used as raw signature	Designed to defeat length-extension attacks (RFC 2104)

Context	How HMAC Is Used
JWT signing (HS256/384/512)	Secret-keyed token signing. HS256 = HMAC-SHA-256 is the default JWT signature; key MUST be at least as long as the hash output.
Webhook verification	GitHub, Stripe, Slack, GitLab — all sign outgoing webhooks with HMAC-SHA-256 and an X-Hub-Signature header for receivers to verify.
AWS Signature V4	Every authenticated AWS request signs the canonical request with HMAC-SHA-256 chained four times through derived keys.
OAuth 1.0 (legacy)	OAuth 1.0a uses HMAC-SHA-1 to sign requests. Modern OAuth 2.0 dropped HMAC in favor of TLS + Bearer tokens.
API request signing	Custom API auth schemes (HMAC headers on requests). Always include a timestamp in the signed payload to prevent replay attacks.
TOTP-derived secrets	Google Authenticator and similar use HMAC-SHA-1 over time + secret. The HOTP/TOTP RFCs (4226, 6238) standardize the algorithm.

Free HMAC Generator: HMAC-SHA-1, SHA-256, SHA-384, SHA-512 in Your Browser

Four Algorithms

Three Output Formats

Native Web Crypto

100% Client-Side

Keyed Message Authentication, Done in the Browser

Plain Hash vs HMAC — When Each Applies

Where HMAC Is Standard in 2026

Five Rules for Using HMAC Safely

Related Security & Crypto Utilities