HMAC Generator

A hash function tells you whether data has changed. It does not tell you whether the change was made by someone you trust. That distinction matters more than it might seem at first, and it is the gap that HMAC fills.

If you send a message with an MD5 or SHA-256 hash attached, anyone who intercepts and modifies the message can simply compute a new hash of the modified content and replace the original. The recipient's hash check passes. The tampered message looks legitimate. The hash proved integrity of the data in transit, but it proved nothing about who created it.

HMAC fixes this by combining the hash function with a secret key. Only someone who knows the key can produce the correct authentication code for a given message. A recipient with the same key can verify that the code is valid and that the message came from a trusted source. An attacker without the key cannot forge a valid code regardless of how they modify the message.

What HMAC Actually Is

HMAC stands for Hash-based Message Authentication Code. It is a specific construction defined in RFC 2104 that wraps any cryptographic hash function with a keyed authentication layer. The underlying hash algorithm can be MD5, SHA-1, SHA-256, SHA-384, SHA-512, or any other approved hash function. The most common choices in current use are HMAC-SHA256 and HMAC-SHA512 because the underlying SHA-2 family algorithms are strong, fast, and universally supported.

The construction works by processing the message and the secret key together in a specific way that prevents length extension attacks and produces an output that is both integrity-verifying and source-authenticating. The mathematical details are well-defined in the RFC and in every serious cryptography textbook, but the practical behavior is what matters for using it correctly: the output is a fixed-length code that cannot be forged without the key and cannot be separated from the specific message it authenticates.

HMAC is not encryption. It does not hide the content of a message. The message is visible to anyone who sees it. What HMAC provides is authentication: proof that the message was created by someone who knows the key and that it has not been altered since it was signed.

How to Use the HMAC Generator

1. Enter the message or data you want to authenticate into the input area.
2. Enter your secret key. This should be a strong, random value that is kept confidential between the parties doing the verification.
3. Select your hash algorithm. HMAC-SHA256 is the recommended default for new implementations.
4. Click the generate button to produce the HMAC.
5. Copy the output to your clipboard with one click, or download it as a file.

For verification, enter the message, the secret key, and the HMAC value you want to check. The tool confirms whether the provided HMAC is valid for that message and key combination.

Everything runs client-side. Your message content and secret key never leave your browser.

Where HMAC Is Used in Practice

HMAC appears throughout the infrastructure of the modern web in places that are not always visible but that matter significantly.

API authentication. Many APIs use HMAC signatures to authenticate requests. The client computes an HMAC over the request parameters using a shared secret key and includes it in the request. The server recomputes the HMAC independently and rejects any request where the signatures do not match. This prevents both tampering with request parameters in transit and replay attacks when combined with a timestamp or nonce in the signed data. AWS Signature Version 4, used for authenticating requests to AWS services, is built on HMAC-SHA256. Stripe's webhook signature verification uses HMAC-SHA256. Shopify's webhook verification uses the same approach.

Webhook signature verification. When a service sends webhook events to your application, it typically signs the payload with an HMAC using a secret key that only you and the service know. Verifying the HMAC before processing the webhook ensures that the request came from the legitimate service and not from an attacker who discovered your webhook endpoint. Skipping this verification is a common and consequential security omission.

JWT validation. JSON Web Tokens signed with the HS256, HS384, or HS512 algorithms use HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 respectively. The token's header and payload are signed with a shared secret, and the signature must be verified before trusting any claims in the token. This is one of the most widely deployed uses of HMAC in web applications.

Message integrity in distributed systems. Systems that pass messages between services, store data in queues, or cache processed results use HMAC to verify that data has not been corrupted or tampered with between the point of creation and the point of consumption. The integrity check adds minimal overhead and catches both accidental corruption and intentional modification.

Cookie and session tamper protection. Web frameworks that store signed cookies compute an HMAC over the cookie value using a server-side secret. Any attempt to modify the cookie value on the client side produces an invalid signature that the server rejects. Django's signed cookies, Flask's session cookies, and Rails' signed cookies all use this pattern.

Choosing the Right Hash Algorithm

The hash function underlying the HMAC determines its security properties and performance characteristics.

HMAC-SHA256 is the right default for new implementations. SHA-256 produces a 256-bit (32-byte) output, provides strong collision resistance, and is hardware-accelerated on essentially every modern processor. It is the algorithm used in AWS signatures, Stripe webhooks, and the majority of modern API authentication schemes.

HMAC-SHA512 provides a larger output (512 bits, 64 bytes) and stronger security margin. It is faster than SHA-256 on 64-bit processors that can process 64-bit words natively. A reasonable choice for high-security contexts or when the larger output size is specifically required.

HMAC-SHA1 was widely deployed in older systems and is still used in some protocols for backward compatibility. SHA-1 has known collision vulnerabilities, though these do not directly compromise HMAC-SHA1's security properties as severely as they compromise SHA-1 used standalone. For new implementations, SHA-256 or SHA-512 is the correct choice. For existing systems using HMAC-SHA1, migration to HMAC-SHA256 is advisable when the opportunity arises.

HMAC-MD5 appears in legacy systems and some older protocols. MD5's collision vulnerabilities are well-documented, and while the keyed construction of HMAC partially mitigates some attack vectors, HMAC-MD5 should not be used for new work. It remains available in this tool for compatibility testing and auditing existing implementations.

For general-purpose hashing without authentication requirements, the MD5 Hash Generator and SHA-256 Hash Generator handle those cases. The distinction to keep clear is that those tools produce unauthenticated hashes, appropriate for checksums and data fingerprinting but not for authentication where a secret key is required.

Key Management Considerations

The security of HMAC depends entirely on the secrecy of the key. A strong HMAC with a weak or compromised key provides no meaningful protection. A few principles that apply directly.

Keys should be randomly generated using a cryptographically secure random number generator. Derived from a passphrase, incrementing integers, or any predictable value, they are not keys in any meaningful security sense.

Key length should match or exceed the output length of the underlying hash function. For HMAC-SHA256, a 256-bit (32-byte) key is the minimum. Shorter keys reduce security. Longer keys are fine; the HMAC construction handles them correctly.

Keys must be kept secret. This sounds obvious until you encounter a production codebase where the HMAC key is hardcoded in version-controlled source code, stored in a public repository, or included in client-side JavaScript where it is visible to anyone who opens the browser's developer tools. A key visible to an attacker renders the HMAC worthless. Store keys in environment variables, secret management systems, or hardware security modules depending on your threat model.

Rotate keys periodically and immediately if compromise is suspected. All systems verifying HMACs signed with the old key need to be updated to use the new key, which is the operational complexity that makes key rotation non-trivial in practice.

HMAC vs Other Authentication Approaches

For developers evaluating how HMAC fits alongside other tools, the distinctions are worth stating clearly.

HMAC is a symmetric authentication mechanism. Both the sender and receiver use the same secret key. This works well for server-to-server communication and internal service authentication where key distribution is controllable. For scenarios where asymmetric authentication is needed, where the verifier should not be able to forge signatures, public-key signature schemes like RSA or ECDSA are the appropriate choice.

HMAC is not encryption. If the message content needs to be confidential in addition to authenticated, encryption is a separate requirement. HMAC over an encrypted message is a valid and recommended pattern for providing both confidentiality and authentication, but HMAC alone does not provide the confidentiality part.

The Argon2 Hash Generator and Bcrypt Hash Generator handle a related but distinct problem: password storage, where the goal is computational difficulty rather than message authentication. Using HMAC for password storage and password hashing functions for message authentication are both category errors that produce insecure implementations.

Frequently Asked Questions

What is HMAC used for?

HMAC is used for message authentication and integrity verification. It produces a cryptographic code that proves a message was created by someone with knowledge of the secret key and that the message has not been altered since it was signed. Common applications include API request authentication, webhook signature verification, JWT signing, and cookie tamper protection.

What is the difference between HMAC and a regular hash?

A regular hash function produces a fixed-length digest from input data. Anyone can compute the hash of any data without any secret. HMAC combines the hash function with a secret key, so only parties who know the key can produce or verify the authentication code. This provides authentication in addition to integrity verification.

Which HMAC algorithm should I use?

HMAC-SHA256 is the recommended default for new implementations. It is widely supported, hardware-accelerated on modern processors, and used in most major API authentication standards. HMAC-SHA512 is appropriate when a larger output or higher security margin is specifically needed.

Is HMAC the same as a digital signature?

No. HMAC is a symmetric authentication scheme where both parties use the same secret key. A digital signature uses asymmetric cryptography where a private key signs and a public key verifies, meaning the verifier cannot produce valid signatures. HMAC is simpler and faster but requires secure key distribution to all verifying parties.

How long should the HMAC key be?

The key length should match or exceed the output length of the hash function. For HMAC-SHA256, use a minimum of 32 bytes (256 bits). For HMAC-SHA512, use a minimum of 64 bytes (512 bits). Keys should be generated using a cryptographically secure random number generator.