HMAC Generator in your browser, no signup

A plain hash proves a message was not altered. It does not prove who sent it, because anyone can compute a SHA-256 of anything - change the message, recompute the hash, and the tampering is invisible. HMAC closes that gap by mixing a secret key into the hashing process. Only someone holding the key can produce a valid code, so a matching HMAC proves both that the message is intact and that it came from a party who knows the secret. This is why it underpins webhook verification: when Stripe, GitHub or Slack send your server an event, they sign the payload with a shared secret, and checking that signature is what stops anyone from posting fake events to your endpoint. The critical implementation detail is comparison. Checking signatures with a normal string equality leaks timing information an attacker can measure to recover the key byte by byte - constant-time comparison is required. Computation here runs in your browser.

Anything that hashes, generates keys or checks a password should stay on your machine. If a site asks you to upload a secret, close the tab.

HMAC Generator is a good fit when verifying a webhook signature from Stripe, GitHub, Slack or a similar provider.

In plain English

HMAC Generator is built around a few practical wins, not a long feature list:

• Proves authenticity as well as integrity, which a plain hash cannot do.
• Supports the SHA-256 algorithm that current systems expect.
• Runs in your browser, so keys and payloads are never transmitted.
• Useful for debugging webhook signature mismatches directly.
• No account and no rate limit.

How to run it

1. Enter your message. The exact payload to sign - for webhook verification this is the raw request body, byte for byte.
2. Enter the secret key. The shared secret. Use a test key rather than a production one when exploring.
3. Choose the algorithm. SHA-256 for anything new. SHA-1 remains only for compatibility with older systems.
4. Compare the result. In real code, compare with a constant-time function, never with a plain string equality check.

Real situations

• Verifying a webhook signature from Stripe, GitHub, Slack or a similar provider.
• Signing an API request where the service requires an HMAC header.
• Debugging why a signature check is failing between two systems.
• Generating a test signature while implementing verification.
• Learning how HMAC differs from plain hashing.

Small habits that help

• Sign the raw request body exactly as received. Parsing to JSON and re-serialising changes the bytes and breaks the signature - this is the most common webhook verification bug.
• Compare signatures with a constant-time function. Normal string comparison exits early on the first mismatch, which leaks the key over many attempts.
• Use SHA-256. SHA-1 is only appropriate when an existing system requires it.
• Check encoding: providers differ on whether the signature is hex or base64, and comparing across formats always fails.
• Store the secret in an environment variable, never in source control.

Skip these

• Re-serialising the payload before signing, so the bytes differ from what the sender signed.
• Using == or === to compare signatures, which is a genuine timing attack vector rather than a theoretical one.
• Confusing HMAC with encryption. It authenticates a message; it does not hide it.
• Comparing a hex signature against a base64 one and concluding the key is wrong.
• Pasting a live production secret into any third-party tool out of habit.

Does anything leave your device?

HMAC Generator runs in your browser. The file or text you paste stays on your device. There is no account, and nothing is stored on a ToolBox server for this job.

Related tools worth opening next

If this is one step in a longer job, these usually come after it:

• SHA-256 Checker - Generate and verify SHA-256 hashes, or sign/verify with HMAC-SHA-256
• PBKDF2 Generator - Derive and verify keys using PBKDF2 in the browser
• SHA-512 Checker - Generate and verify SHA-512 hashes from text or files

FAQ

How is HMAC different from a regular hash like SHA256?

A regular hash only proves data integrity (that it wasn't altered) but anyone can compute it. HMAC additionally requires a secret key, so it proves the message came from someone who knows that key - adding authentication on top of integrity verification.

What is HMAC commonly used for?

API request signing (verifying a request genuinely came from an authorized client), webhook payload verification, and various authentication protocols where you need to confirm both integrity and origin of a message.

Is it safe to test with a real secret key here?

Computation happens entirely in your browser and nothing is transmitted. Even so, avoid pasting production secrets into any third-party tool as a matter of habit - use a test key when learning or debugging.

Why is my webhook signature check failing?

Almost always because the payload was parsed and re-serialised before signing. HMAC is computed over exact bytes, and JSON.parse followed by JSON.stringify changes key order and whitespace. Sign the raw body exactly as received.

Why does signature comparison need to be constant-time?

Because ordinary string comparison returns as soon as it finds a difference. An attacker can measure that timing across many attempts to work out the correct signature one byte at a time. Every language has a constant-time comparison function for exactly this.

Should I use SHA-1 or SHA-256?

SHA-256 for anything new. HMAC-SHA1 is not broken in the way plain SHA-1 is, but there is no reason to choose it today - use it only when an existing system requires it.

Open the HMAC Generator when you are ready. It is free, and you do not need an account.