HMAC Generator

About HMAC Generator

HMAC (Hash-based Message Authentication Code) verifies both the integrity and authenticity of a message using a secret key. This tool generates HMAC signatures using SHA-256, SHA-384, SHA-512, or SHA-1, with output in hex or base64 format. All computation uses the browser's Web Crypto API - your key and message never leave your device.

How HMAC Works

HMAC combines a secret key with a message and runs them through a hash function in a specific way: HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)). The double hashing with inner and outer padding prevents length extension attacks that affect plain hash(key + message) constructions.

Component	Purpose
Secret key	Known only to sender and receiver - proves authenticity
Message	The data being signed (API request body, webhook payload, etc.)
Hash function	Produces fixed-length output (SHA-256, SHA-512, etc.)
Inner padding (ipad)	XOR with 0x36 - used in the inner hash
Outer padding (opad)	XOR with 0x5c - used in the outer hash

HMAC vs Plain Hashing

Property	Hash (SHA-256)	HMAC (HMAC-SHA-256)
Inputs	Message only	Message + secret key
Anyone can compute?	Yes	No - requires the secret key
Proves authenticity?	No	Yes - only key holders can generate valid signatures
Proves integrity?	Yes (if you trust the hash source)	Yes (guaranteed by the key)
Vulnerable to length extension?	Yes (SHA-256, SHA-512)	No - HMAC construction prevents this

Supported Algorithms

Algorithm	Output (hex)	Output (base64)	Status
HMAC-SHA-256	64 characters	44 characters	Recommended - most widely used
HMAC-SHA-384	96 characters	64 characters	Good - larger output
HMAC-SHA-512	128 characters	88 characters	Good - maximum security margin
HMAC-SHA-1	40 characters	28 characters	Legacy only - do not use for new systems

Where HMAC Is Used

Service	Use Case	Algorithm	How It Works
AWS Signature V4	API request signing	HMAC-SHA-256	Signs request method, headers, and body with derived key
Stripe webhooks	Payload verification	HMAC-SHA-256	Signs timestamp + payload with endpoint secret
GitHub webhooks	Payload verification	HMAC-SHA-256	Signs raw body with webhook secret (X-Hub-Signature-256)
Slack	Request verification	HMAC-SHA-256	Signs timestamp:body with signing secret
JWT (HS256)	Token signing	HMAC-SHA-256	Signs header.payload with shared secret
TOTP (2FA codes)	One-time passwords	HMAC-SHA-1	Signs time-based counter with shared secret
OAuth 1.0	Request signing	HMAC-SHA-1	Signs base string with consumer + token secrets

Verifying a Webhook Signature

Most webhook providers send a signature in a header (like X-Hub-Signature-256). To verify, you compute the HMAC of the raw request body using your webhook secret and compare it to the received signature.

Step	Action
1	Get the signature from the request header
2	Get the raw request body (before any parsing)
3	Compute HMAC of the body using your secret key
4	Compare computed signature to received signature using constant-time comparison
5	Reject the request if signatures do not match

Always use constant-time comparison (like crypto.timingSafeEqual in Node.js) to prevent timing attacks. A regular string comparison (===) leaks information about which characters match.

Key Length Recommendations

Algorithm	Recommended Key Length	Why
HMAC-SHA-256	32+ bytes (256 bits)	Match the hash output length for optimal security
HMAC-SHA-512	64+ bytes (512 bits)	Match the hash output length
Any HMAC	At least 16 bytes (128 bits)	Absolute minimum to prevent brute force

Keys shorter than the hash block size are padded, and keys longer than the block size are hashed first. Using a key that matches the hash output length gives the best security without unnecessary overhead.

For non-keyed hashing (file checksums, data fingerprinting), the Hash Generator supports SHA-256, SHA-512, and MD5. For data encryption rather than signing, the Encryption/Decryption Tool handles AES encryption. All computation runs in your browser via the Web Crypto API.