CodeKitHubWhat Is This Tool?
HMAC stands for Hash-based Message Authentication Code. It combines a secret key with a message and a standard hash function (like SHA-256) to produce a fixed-length digest. Anyone with the same key and message will compute the exact same HMAC — but without the key, it's computationally infeasible to produce a valid HMAC for a message, even if you know the hash algorithm being used.
That's the key difference from a plain hash: a plain hash (MD5, SHA-256, etc.) takes only the message as input, so anyone can compute it and it proves nothing about who created it. An HMAC takes the message *and* a secret key, so a valid HMAC proves the sender possessed the secret — it's an authentication mechanism, not just an integrity check.
HMAC is formally standardized by NIST in FIPS 198-1 and defined for internet protocols in IETF RFC 2104. This tool computes HMACs using your browser's native Web Crypto API (`crypto.subtle.sign` with the HMAC algorithm), which implements RFC 2104 correctly rather than a hand-rolled JavaScript version.
Why Use It?
- A webhook handler you're debugging is rejecting every request as "invalid signature" — paste in the shared secret and the exact raw payload body here to compute the HMAC yourself and see whether your server-side comparison logic is the actual bug.
- You're implementing API request signing for the first time and want to confirm your code produces the right HMAC-SHA256 before you point it at a production endpoint that will silently reject bad signatures.
- You're generating a one-off signed URL or token for a service that authenticates with a shared secret, and it's faster to compute the HMAC here than to spin up a script for a single value.
- You're teaching or learning how HMAC differs from a plain hash, and want to watch the same message produce a completely different digest the moment you add or change the secret key.
- You're comparing HMAC-SHA1 against HMAC-SHA256 output for the same key and message to confirm a legacy system's signature scheme before migrating it to a stronger algorithm.
- 100% local: your secret key and message never leave the browser, so it's safe to test real secrets.
How to Use
- Enter your secret key in the "Secret Key" field.
- Enter the message you want to authenticate in the "Message" field.
- The HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512 results are generated instantly (check "Uppercase output" if your target system expects capital letters).
- Click "Copy" next to whichever HMAC you need.
Example
Input
Secret Key: key
Message: The quick brown fox jumps over the lazy dogOutput
HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9This is a standard published test vector: with key "key" and this exact message, HMAC-SHA256 and HMAC-SHA1 always produce these values on any correct implementation, so you can verify this tool's output independently.
HMAC vs plain hash: when you need a key
The deciding question is: do you need to prove who created this digest, or just that the content hasn't changed? If a public checksum is enough — verifying a downloaded file matches what the publisher listed, deduplicating records — a plain hash works and anyone can check it, key-free. If you need to prove the digest could only have been produced by someone holding a specific secret — authenticating an API caller, trusting a webhook's sender — you need HMAC, because a plain hash gives an attacker with no secret the same ability to forge a valid digest as the real sender.
→ Multi-Algorithm Hash Generator · JWT Decoder · MD5 Generator
Comparing the four HMAC algorithms
All four use the same HMAC construction from RFC 2104, differing only in the underlying hash function and therefore the output length.
| Algorithm | Output size | Typical use |
|---|---|---|
| HMAC-SHA1 | 160-bit (40 hex chars) | Legacy APIs, older OAuth 1.0a signatures |
| HMAC-SHA256 | 256-bit (64 hex chars) | API request signing, JWT HS256, webhook verification |
| HMAC-SHA384 | 384-bit (96 hex chars) | Higher-assurance signatures where longer output is required |
| HMAC-SHA512 | 512-bit (128 hex chars) | Maximum-length digests for high-security applications |
Common use cases
- Signing outgoing API requests with a shared secret so the server can verify the caller's identity.
- Verifying incoming webhook payloads (Stripe-Signature, GitHub X-Hub-Signature-256 and similar headers all use HMAC-SHA256).
- Generating and validating the signature portion of a JWT signed with HS256/HS384/HS512.
- Testing that your server-side or client-side HMAC implementation matches expected output before deploying it.
Debugging a webhook signature mismatch step by step
Signature verification failures are one of the most common HMAC-related bugs, and they almost always trace back to a mismatch between the bytes you're hashing and the bytes the sender actually hashed — not a broken algorithm.
Start by confirming you're hashing the raw request body exactly as received, before your framework parses it into an object — many web frameworks buffer and re-encode the body in ways that silently change whitespace or key order once you've touched `req.body`. Next, confirm the secret: many providers issue a different signing secret per webhook endpoint or environment, so a secret copied from the wrong dashboard tab will produce a mismatch that looks identical to a code bug. Finally, check the encoding of the output — some services expect the HMAC as lowercase hex, others as base64, and comparing a correct HMAC in the wrong encoding format will fail even though the underlying computation is right. Reproducing the exact scenario here, with the same raw text and secret, isolates whether the problem is your comparison logic or the inputs feeding it.
Frequently Asked Questions
What is HMAC?
HMAC (Hash-based Message Authentication Code) combines a secret key with a message using a hash function to produce a digest that proves both the message's integrity and the sender's possession of the key. It's defined in NIST FIPS 198-1 and IETF RFC 2104.
What's the difference between HMAC and a plain hash?
A plain hash (SHA-256, MD5, etc.) takes only a message as input — anyone can compute it, so it only proves the message wasn't corrupted, not who sent it. An HMAC takes a message plus a secret key: if you need to prove a message came from someone who holds a specific secret (an API signature, a webhook sender), you need HMAC. If you only need to check a file or message hasn't changed and don't care about proving authorship, a plain hash is enough.
Is my secret key sent to a server?
No. This tool computes the HMAC entirely in your browser using the Web Crypto API. Your key and message are never transmitted anywhere — you can safely test real production secrets.
Which algorithm should I use — SHA-1, SHA-256, SHA-384 or SHA-512?
Use HMAC-SHA256 unless a specific system requires otherwise — it's the de facto standard for API signing (used by AWS, Stripe, GitHub webhooks and most modern APIs) and offers a strong security margin. HMAC-SHA1 is still common in legacy systems (like older OAuth 1.0a implementations) but SHA-1's underlying hash is considered weaker; HMAC-SHA384/512 are used where longer output or extra security margin is specifically required.
Is HMAC-SHA1 unsafe, since plain SHA-1 is broken?
The 2017 collision attacks against SHA-1 broke SHA-1 as a plain hash function, but HMAC-SHA1 is still considered cryptographically sound because HMAC's security doesn't depend on collision resistance the same way. That said, prefer HMAC-SHA256 or higher for new systems — there's no practical downside and it avoids the question entirely.
What are common real-world uses of HMAC?
Signing REST API requests so a server can verify the caller holds the shared API secret; verifying webhook payloads from services like Stripe, GitHub and Shopify so you know a request genuinely came from them and wasn't forged; generating time-based one-time passwords (TOTP/HOTP) for two-factor authentication; and signing JWT tokens with the HS256/HS384/HS512 algorithms.
Why doesn't my webhook signature match the HMAC this tool computes with the same secret?
The single most common cause is that the raw request body sent to the HMAC function doesn't exactly match what the sending service actually hashed — a re-serialized JSON body (with different key ordering, whitespace, or escaping than the original bytes) produces a completely different HMAC even though it "looks" identical. Always compute the HMAC against the exact raw request body/text, before any JSON parsing, and double-check you're using the correct secret (some services provide separate signing secrets per webhook endpoint).
Does the length of my secret key affect how secure the HMAC is?
Yes, up to a point — a very short or guessable secret (like "password" or a 4-digit PIN) is the weak link regardless of how strong the hash algorithm is, since an attacker can brute-force short keys directly. HMAC's design recommends a key at least as long as the underlying hash's output size; beyond that length, adding more key length stops meaningfully improving security.
Can two different messages produce the same HMAC output with the same key?
In theory yes, since HMAC maps an unlimited input space onto a fixed-length output — but for SHA-256 and above, this kind of collision is considered computationally infeasible to find deliberately with any known attack, which is exactly why HMAC-SHA256 is trusted for production signing despite the mathematical possibility.
Is this tool computing HMAC in a way that's identical to how my backend language (Node, Python, etc.) computes it?
Yes — because this tool uses the browser's native Web Crypto API rather than a hand-written implementation, it follows the same RFC 2104 specification that Node's crypto module, Python's hmac library, and virtually every other correct HMAC implementation follow. Matching output here is a reliable way to confirm your backend code is implementing the spec correctly.