HMAC (Hash-based Message Authentication Code) is a specific type of message authentication code that combines a cryptographic hash function with a secret key. Unlike a simple hash, which anyone can compute for any message, an HMAC requires knowledge of the secret key to generate or verify. This makes HMACs essential for authenticating messages and verifying data integrity in scenarios where you need to confirm both that data hasn't been modified and that it came from a trusted source.
Our HMAC Generator uses the Web Crypto API to perform all calculations directly in your browser. Your message and secret key are never transmitted to any server. This is particularly important when working with HMACs, as the secret key is the foundation of the security—if the key is compromised, the authentication provides no protection.
How HMAC Works
HMAC combines a hash function with a secret key using a specific construction designed by cryptographers. The algorithm processes the key and message in a way that prevents various attacks that could work against naive implementations. Specifically, HMAC uses the formula: HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), where H is the hash function, K' is the key padded to the block size, and ipad/opad are specific padding constants.
This construction provides several important security properties. First, the output depends on both the message and the key—changing either produces a completely different HMAC. Second, without knowing the key, an attacker cannot forge a valid HMAC for a new message, even if they've seen HMACs for other messages. Third, the construction is resistant to length extension attacks that affect plain hash functions.
Choosing an Algorithm
HMAC-SHA-256 produces a 256-bit (64 hexadecimal characters) output and is the most widely used variant. It's specified in numerous standards and protocols including TLS, OAuth, and various API authentication schemes. HMAC-SHA-256 provides an excellent balance of security and performance for virtually all applications.
HMAC-SHA-512 produces a 512-bit (128 hexadecimal characters) output and offers a larger security margin. On 64-bit processors, SHA-512 can actually be faster than SHA-256 due to its use of 64-bit operations. Choose HMAC-SHA-512 when you need the highest security level or when working with systems that specifically require it.
Common Use Cases
API authentication is one of the most common applications of HMAC. Services like AWS, Stripe, and GitHub use HMAC signatures to verify that API requests originate from authorized clients and haven't been tampered with. The client creates an HMAC of the request parameters using a shared secret, and the server verifies this signature before processing the request.
Webhook verification follows a similar pattern. When services send webhooks to your application, they typically include an HMAC signature computed with a shared secret. By recalculating the HMAC on your end and comparing it to the provided signature, you can verify the webhook actually came from the expected service and wasn't forged by an attacker.
Token generation for things like password reset links or email verification often uses HMAC. By including user-specific data in the message and computing an HMAC with a server-side secret, you create tokens that cannot be forged or modified without access to the secret key.
Security Best Practices
The security of HMAC depends entirely on the secrecy and strength of the key. Use cryptographically random keys with sufficient length—at least 32 bytes (256 bits) for HMAC-SHA-256 and 64 bytes (512 bits) for HMAC-SHA-512. Never use predictable values like user IDs or timestamps as keys.
When comparing HMAC values for verification, use constant-time comparison to prevent timing attacks. Many programming languages provide specific functions for this purpose. Never use simple string equality checks for HMAC verification in production code.
Treat your secret keys like passwords—never commit them to version control, never log them, and rotate them periodically. Use environment variables or secure secret management systems to store and access keys in production environments.
Important Warning
While this tool is perfect for learning, testing, and development, exercise caution with production secrets. Even though processing happens entirely in your browser, you should avoid pasting actual production API keys or secrets into any web-based tool. For production HMAC generation, use server-side code with proper secret management.
Common Use Cases
API Request Authentication
Generate HMAC signatures for API requests to prove the request originated from an authorized client and hasn't been modified.
Webhook Signature Verification
Create or verify HMAC signatures for webhooks to ensure they came from the expected source and weren't tampered with.
Token Generation
Generate secure tokens for password resets, email verification, or session management that cannot be forged without the secret key.
Message Integrity Verification
Attach HMAC signatures to messages or data transfers to detect any modifications during transmission.
Learning and Development
Understand how HMAC works by experimenting with different messages and keys, seeing how the output changes.
Testing API Integrations
Generate test HMAC values during development to verify your API signature implementation matches expected outputs.
Worked Examples
Basic HMAC Generation
Input
Message: Hello, World! Secret Key: my-secret-key
Output
HMAC-SHA-256: 68c0d8d75b1d0e8f8c5d5e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b
The HMAC combines the message with the secret key to produce a signature. Only someone with the same secret key can generate this exact output.
API Signature Example
Input
Message: POST /api/payment amount=100¤cy=USD×tamp=1699999999 Secret Key: sk_live_abc123
Output
HMAC-SHA-256: (signature varies based on exact input)
This simulates creating an API signature by hashing the request method, path, and parameters with the secret key. The server recalculates this to verify the request.
Frequently Asked Questions
What is the difference between HMAC and a regular hash?
A regular hash like SHA-256 only requires the message—anyone can compute it. HMAC requires both the message and a secret key, so only parties who know the key can generate or verify the HMAC. This adds authentication to the integrity check.
Is my secret key sent to a server?
No. All HMAC computation happens locally in your browser using the Web Crypto API. Your message and secret key never leave your device. You can verify this by disconnecting from the internet—the tool continues to work.
Should I use HMAC-SHA-256 or HMAC-SHA-512?
HMAC-SHA-256 is sufficient for virtually all applications and is the most widely supported. Use HMAC-SHA-512 if you need a larger security margin or if it's specifically required by your integration. On 64-bit systems, SHA-512 may actually be faster.
Can I use this tool to verify webhook signatures?
Yes! Enter the webhook payload as the message and your webhook secret as the key. Compare the generated HMAC with the signature provided in the webhook headers. Make sure you use the same algorithm (usually SHA-256) as the sending service.
How long should my secret key be?
Use at least 32 bytes (256 bits) for HMAC-SHA-256 and 64 bytes (512 bits) for HMAC-SHA-512. Keys should be randomly generated—don't use predictable values. Shorter keys still work but provide reduced security.
Is it safe to paste production secrets here?
While processing is entirely local and no data is sent to servers, we recommend against pasting production secrets into any web tool as a general security practice. Use this tool for learning, testing with development keys, or generating HMACs for non-sensitive purposes.
