HMAC (Hash-based Message Authentication Code) combines a cryptographic hash function with a secret key to produce a signature. It proves both that a message has not been tampered with (integrity) and that the sender knows the secret key (authenticity).

Which algorithm should I use?

HMAC-SHA-256 is the most widely used choice and is secure for the vast majority of applications. HMAC-SHA-512 offers a larger output (512 bits) and may be slightly faster on 64-bit systems. HMAC-SHA-1 is considered cryptographically weak and should only be used when required by a legacy protocol.

What output encoding should I choose?

Hex produces a lowercase hexadecimal string (e.g., "a94a8fe5..."). Base64 produces a shorter string using letters, digits, + and / (e.g., "qUqP5cyxm6..."). Both represent the same bytes - choose whichever format your API or protocol expects.

Can I enter the key as hex bytes?

Yes. Switch the key encoding to "Hex" and paste a hex-encoded key (e.g., "0b0b0b0b..."). This is useful when testing against published test vectors or working with binary keys.

Does my secret key leave my browser?

No. All HMAC computation runs in your browser using the built-in Web Crypto API (crypto.subtle). Neither your message nor your key is ever transmitted to any server.

HMAC Generator (SHA-256 / SHA-512)

What is HMAC?

HMAC (Hash-based Message Authentication Code) is a cryptographic technique that combines a secret key with a hash function (such as SHA-256) to produce an authentication tag for a message. It is defined in RFC 2104 and used extensively in APIs, JWTs, webhooks, and secure protocols.

What is HMAC used for?

HMAC is used wherever you need to verify that a message both arrived intact (integrity) and was produced by someone who knows the shared secret (authenticity). Common use cases include:

Signing API requests (AWS Signature V4, Stripe webhooks, GitHub webhooks)
JSON Web Tokens (the HS256 / HS512 algorithms)
Secure cookie signing
TOTP and HOTP one-time password generation

HMAC-SHA-256 vs HMAC-SHA-512

Both are secure. HMAC-SHA-256 produces a 256-bit (64 hex character) tag and is the most commonly required algorithm. HMAC-SHA-512 produces a 512-bit (128 hex character) tag and is marginally faster on 64-bit processors. HMAC-SHA-1 is cryptographically weak and should only be used when a legacy protocol explicitly requires it.

Key length guidance

For maximum security, an HMAC key should be at least as long as the hash output: 32 bytes (256 bits) for HMAC-SHA-256, and 64 bytes (512 bits) for HMAC-SHA-512. Longer keys beyond these thresholds provide no additional security benefit (they are hashed down to the block size internally). Shorter keys significantly weaken HMAC security and should be avoided.

Common use cases

Use case	Details
JWT signatures (HS256/HS512)	Signs the header+payload; shared secret between issuer and verifier
Webhook verification	GitHub, Stripe, and Shopify include an HMAC in the `X-Hub-Signature` header so receivers can verify the payload
API request authentication	AWS Signature Version 4 signs requests using HMAC-SHA-256
Signed cookie values	Frameworks like Django and Express sign session cookies with HMAC to prevent tampering

Timing attack warning

When verifying an HMAC, always use constant-time comparison rather than a simple string equality check (===). A standard string comparison short-circuits at the first mismatched character, leaking timing information an attacker can exploit to forge valid HMACs byte-by-byte. In Node.js, use crypto.timingSafeEqual(expected, actual); most languages provide an equivalent function.

Privacy

All HMAC computation runs in your browser using the native Web Crypto API (crypto.subtle). Neither your message nor your secret key is ever transmitted to any server.