HMAC Generator

Use this HMAC generator to turn your message and a secret key into a hash-based message authentication code, so the other side can confirm that what arrived is exactly what you sent.

What an HMAC Generator Does With Your Message

An HMAC is a keyed hash: a cryptographic hash function is run over your message together with a shared secret, and the result is a short, fixed-length fingerprint. Anyone holding the same secret can recompute it and confirm the data was not tampered with in transit, which gives you both data integrity and authenticity. A plain hash cannot do that, because anybody can recompute a hash from the message alone. An HMAC is one kind of MAC, and it is the one almost every payments platform expects. The drupal password hash generator is completely free to use, with no rate limits, watermarks, or hidden restrictions.

The formula behind every HMAC algorithm is:

$$\text{HMAC}(K, m) = H\big((K' \oplus \text{opad}) \parallel H((K' \oplus \text{ipad}) \parallel m)\big)$$

Here \(H\) is the hash function, \(K'\) is the key adjusted to the hash's block size, \(m\) is the message and \(\parallel\) means concatenation. A short secret is filled out with zero padding; a secret longer than the block is hashed first.

How to Use This HMAC Signature Generator

1. Enter your message. Paste the exact plain text or JSON body you want to sign. A single extra space produces a completely different result.
2. Add the secret key. Type or paste the value you share with the other party.
3. Pick the variant. Choose SHA-256 unless an integration asks for something else.
4. Choose the output encoding. Select hex or Base64, whichever your receiving system expects.
5. Copy the result. The code updates as you type, so you can adjust any input and watch it change.

It is free to use, and you can generate HMAC online without creating an account. The HMAC tool is client-side only: nothing is stored, and the message and secret never go to a server. The sha256 hash generator is completely free to use, with no rate limits, watermarks, or hidden restrictions.

Why the Web Crypto API Keeps Your Secret Key Local

The page calls the browser's built-in Web Crypto API to compute each code, so the calculation happens in your browser rather than on a remote machine. That makes it private enough to test with a real value, though a production secret still deserves care.

Hex or Base64 Output

Both formats carry the same HMAC bytes, and the output selector on this tool switches between them. The first uses two characters per byte, while the second packs three bytes into four characters, so it runs about a third shorter. Check what the receiving documentation says; a code that is correct but encoded the wrong way will still fail the comparison against the provider's HMAC.

Which HMAC Algorithm to Pick: SHA-256, SHA-384, SHA-512 or SHA-1

The wider the hash, the longer the output. All four options below accept any key length, so choose by what your counterpart supports.

Worked Example: Signing an Order With HMAC-SHA256

Suppose a shop sends the body {"order":"PH-48213","amount":2749,"currency":"EUR"} and both sides hold the secret tallow-ember-9027. Entering them with the 256-bit option gives the codes below, in both encodings.

• Hex: 9eee950a20ef469e646fac4bab4600463500115b9cbcd6d1ac5499f2c34eec4b
• Base64: nu6VCiDvRp5kb6xLq0YARjUAEVucvNbRrFSZ8sNO7Es=

Hashing the same text with no key at all yields 292d6022adcd0f21803c0c49055cfcefd1b5a5d9e647f8e9a6d6ece568a9c88c, which anyone could compute, so it proves nothing about who sent it. Switching to HMAC-SHA512 doubles the output to 128 hex characters, beginning 81a8184bfb73873b.

The check is exact: change the amount from 2749 to 2750 and the whole code changes, not just its last digits. That avalanche behaviour is what makes the code a trustworthy seal.

How to Verify HMAC Signatures With a Timing-Safe Check

To verify HMAC output, recompute the code from the message you received using your own copy of the secret, then compare it with the one that was sent. Never compare with a plain equality operator. A timing-safe function such as crypto.timingSafeEqual in Node.js or hmac.compare_digest in Python takes the same time wherever the first mismatch occurs, so an attacker cannot learn the correct code one byte at a time. Compare the raw digest or the same encoded string, never a mixture.

When the signature you computed equals the signature you received, accept the request; otherwise reject it. A failed verification almost always means the bytes differ, not that the maths is broken, so look for a trailing newline, re-encoded JSON, a changed field order or invisible whitespace in the stored value before suspecting anything else.

Webhook Signature Checks

A webhook signature is the HMAC a provider such as GitHub, Stripe or Slack attaches to each delivery, usually in a request header. Your server should recompute it over the raw body before any JSON parsing, because re-serialising the data changes its bytes. If the provider also signs a timestamp together with the payload, you can reject stale requests and block replay attacks.

Troubleshooting a Mismatched HMAC Result

If your HMAC differs from a provider's documented value, work through the usual suspects in order. Confirm that both sides sign the exact same text, down to line endings and quotation marks. Check that the HMAC output format matches, because a correct code in the wrong format looks like a failure. Check that the same hash variant was chosen on both ends, since each gives a different length of result, and make sure nothing in between trims, decodes or re-orders the input. Then run the provider's sample through this page and through your own program side by side: many providers publish a sample body, a sample secret and the expected HMAC, so entering all three here shows which of the four causes you are facing before a single line of your own handler exists.

Message Authentication Use Cases: Webhooks, JWT and Cookies

Because the sender and receiver share one secret, the scheme is much faster than RSA-based digital signatures, at the cost that either side could forge a code. Typical uses include:

• API authentication: sign each request so the receiving service knows the caller holds the key.
• JWT: the HS256, HS384 and HS512 names in a token header simply mean HMAC with the matching hash width.
• Signed cookies and session tokens that cannot be edited by the user.
• CSRF tokens bound to a user session.
• OAuth 1.0 request signing.
• Signed URLs for expiring downloads.

Data Integrity for Signed Requests

Signing the method, path, timestamp and body together with an HMAC lets the recipient detect any change to a request, and the secret rules out impersonation by a third party. Keep the signed fields in a fixed order so both sides build the same string, then run that string through the generator to confirm the code you expect.

Debugging a Failed Webhook Check With an HMAC Signature Generator

Ines Marchetti's billing service rejects every invoice.paid delivery from GitHub-style tooling with a 401, yet the provider's dashboard insists the requests are valid. She suspects her handler, not the sender, so she opens the delivery log and copies two things: the raw body {"event":"invoice.paid","id":"evt_7714","cents":18450} and the header value a19f734a3c393eab96037924445bec21c496fd4ccc6d4598ceb0b910fcc0cd5d.

In the generator she pastes the body as the message, enters the signing secret whsec_r4Vq81ZtLm, selects HMAC-SHA256 and picks hex, since the provider's documentation states a hex digest. The output is a19f734a…cc0cd5d, identical to the header character for character. The delivery was genuine, and the secret stored in her config is the right one.

That narrows the problem to the bytes her service hashes. She logs the body her code actually feeds into the comparison and sees a trailing space, added by a logging middleware that re-serialises the request. She adds that space to the message in the generator and the code becomes 62633b8f…bb9ae7, exactly the value her server computes, and exactly why the check fails.

Her next action is specific: move the signature check ahead of the body parser, so it reads the untouched request stream, and keep the comparison timing-safe. She redeploys, replays evt_7714 from the dashboard, and the 401 becomes a 200. Total time: about ten minutes, most of it spent proving the signature was never the culprit.

When Not to Use HMAC

HMAC is not encryption: the message stays readable, and the code only proves who produced it. It is also a poor fit for storing a password, because it is designed to be fast. For password hashing and key derivation, use a deliberately slow function instead.

HMAC Secret Generator Best Practices

A strong code needs a strong key. Follow these rules whenever you create or handle one:

• Draw at least 32 random bytes from a cryptographic source, for example with OpenSSL, to reach 256 bits of entropy.
• Keep the secret out of front-end code and version control, and rotate it if it leaks.
• Reserve MD5-based codes for legacy integrations only, and move off them when you can.
• Use the generator for testing a provider's sample request before you write your own handler, then confirm the same result in your security review.
• Reject signatures that are missing, malformed or computed over a different encoding.

Frequently Asked Questions

What's the difference between HMAC and a plain hash?

A plain hash (like SHA-256 alone) only proves a message hasn't changed if the hash itself is protected from tampering -- anyone can recompute a plain hash. HMAC combines the message with a secret key using a specific construction (HMAC(K,m) = H((K⊕opad) || H((K⊕ipad) || m))), so only someone who knows the secret key can produce or verify a matching HMAC -- it proves both integrity and authenticity.

What is HMAC commonly used for?

Verifying webhook payloads (many APIs sign requests with an HMAC so you can confirm they really came from that service), API request signing, JWT signature verification (the HS256/HS384/HS512 algorithms are exactly HMAC-SHA256/384/512), and session token integrity checks.

Which hash algorithm should I use?

HMAC-SHA256 is the most common modern default and is what this tool selects by default. Use whichever algorithm the system you're integrating with specifies -- HMAC's security only requires the underlying hash to be reasonably strong, so SHA-1 is still acceptable for HMAC (unlike for plain hashing) even though it's deprecated elsewhere, but SHA-256 or better is preferred for new systems.

Can I verify an HMAC I received, not just generate one?

Yes -- enter the same message and the same secret key the sender used, and compare this tool's output to the HMAC value you received. If they match exactly, the message is verified as authentic and unmodified.

Is my message or secret key sent anywhere?

No. The entire HMAC computation runs locally using the Web Crypto API -- neither the message nor the secret is ever transmitted to a server or stored.