HMAC Generator - Free Online Hash Tool

HMAC in the Wild — Where You're Already Relying on It

HMAC shows up in nearly every API you've integrated with. Recognising it helps you implement your own correctly.

Platform / Protocol	HMAC variant	What it signs	Header / field name
GitHub Webhooks	HMAC-SHA256	Raw request body	`X-Hub-Signature-256: sha256=<hex>`
Stripe Webhooks	HMAC-SHA256	Timestamp + raw body (replay protection built in)	`Stripe-Signature: t=<ts>,v1=<hex>`
Shopify Webhooks	HMAC-SHA256	Raw request body	`X-Shopify-Hmac-Sha256: <base64>`
AWS Signature V4	HMAC-SHA256 (chained)	Date → region → service → request — four nested HMACs	`Authorization: AWS4-HMAC-SHA256 Credential=...`
JWT (HS256)	HMAC-SHA256	Base64URL(header) + "." + Base64URL(payload)	`.<signature>` — the third dot-segment of the token
TOTP / HOTP (2FA)	HMAC-SHA1 (HOTP) or HMAC-SHA256/SHA512 (TOTP)	Counter or timestamp	The 6-digit code is derived from the last 4 bytes of the HMAC output
OAuth 1.0a	HMAC-SHA1	Normalized request string	`oauth_signature` parameter

How to Implement Webhook Signature Verification Correctly

Most webhook libraries have done this right. If you're writing your own, these are the places where implementations go wrong.

Use the raw body, not the parsed object

JSON parsers normalise whitespace, reorder keys, and drop unknown fields. If you sign the parsed-then-re-serialised body instead of the original bytes, your HMAC will not match what the sender computed. Buffer the raw request body before it hits any JSON parser. In Express this means express.raw() on the webhook route, not express.json().

Use constant-time string comparison

A regular string comparison (===, ==) exits early on the first differing byte. An attacker can measure response latency to learn how many characters of their crafted signature match the expected value. Use crypto.timingSafeEqual() in Node, hmac.compare_digest() in Python, hash_equals() in PHP. This is not optional.

Verify the timestamp to prevent replay attacks

An HMAC doesn't expire. If you verify only the signature, an attacker who intercepts a valid signed request can replay it minutes or days later. Stripe's webhook format includes a timestamp in the signed payload and rejects requests older than 5 minutes. Build the same pattern into your own webhook handlers.

Key length: at least as long as the hash output

The HMAC spec (RFC 2104) says keys shorter than the hash output length provide reduced security. For HMAC-SHA256, use a key that's at least 32 bytes / 256 bits. In practice, use 32 bytes of cryptographically random data. A human-readable string used as a key is likely too short and has low entropy.

HMAC ≠ encryption — it's authentication

HMAC proves who signed a message and that it hasn't been modified. It does not hide the message content. If your payload contains sensitive data, you still need encryption separately. HMAC + plaintext != confidentiality. For confidentiality + integrity together, use AES-GCM or ChaCha20-Poly1305, which include authentication built in.

HMAC-SHA256 vs JWT asymmetric signing

HMAC requires both parties to share the same secret key. Anyone who can verify an HMAC-signed JWT can also forge one. If you're issuing JWTs to external parties, use RS256 or ES256 (asymmetric) instead — your private key signs, and the public key verifies without being able to forge. HMAC-signed JWTs only make sense for internal, single-service scenarios.

HMAC Algorithm Comparison

Choosing between HMAC-SHA256 and HMAC-SHA512 for new work.

Property	HMAC-SHA256	HMAC-SHA512	HMAC-SHA1
Output size	32 bytes / 64 hex chars	64 bytes / 128 hex chars	20 bytes / 40 hex chars
Security level	128-bit (collision), 256-bit (preimage)	256-bit (collision), 512-bit (preimage)	Deprecated for new use
Speed on 64-bit CPU	Good	Often faster (larger block = fewer rounds per byte)	Fastest
Ecosystem support	Universal — every library, every platform	Universal	Universal (legacy)
Use for new work?	Yes — default choice	Yes — prefer for high-value signing	No — only for TOTP/HOTP backward compat

Related Tools

Other free security and hashing tools on IndexCraft.

Common Questions

HMAC is symmetric — both the signer and verifier need the same secret key. This means the verifier could also forge signatures. RSA and ECDSA signatures are asymmetric — a private key signs, and a separate public key verifies. The verifier cannot forge. HMAC is faster and simpler; asymmetric signatures are better when the verifier is untrusted or when you need non-repudiation (proof that only the key holder signed it).

RFC 2104 defines HMAC as H((K XOR opad) || H((K XOR ipad) || message)). The double-pass construction closes off length-extension attacks that affect raw SHA-256 and MD5. With a single-pass construction H(key || message), an attacker who knows the hash but not the key can compute a valid hash for any extension of the message. The outer hash with a different key derivation breaks this.

You technically can, but you shouldn't. Using one key to sign both webhook payloads and API tokens means that a leak of one allows forgery of both. Key separation is a foundational security principle. The standard pattern is to derive purpose-specific keys from a single master key using HKDF: HKDF(masterKey, salt, "webhook-signing") produces a deterministic but purpose-specific subkey. Each derived key is independent.

Treat HMAC secret keys like database passwords — never hardcode in source, never commit to git. Options in order of preference: a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager), environment variables injected at runtime, encrypted configuration files with the encryption key stored separately. Rotate keys regularly and have a plan for what happens when a key is leaked — can you invalidate all signatures issued with it?

🔑 HMAC Generator

HMAC — How It Works & When to Use It

What is HMAC?

Webhook Verification

JWT Signing

Constant-Time Verify