Runs in your browser. Your files and text never leave your device - nothing is uploaded.
Generate an HMAC-SHA256 Signature Online
The Tools Kit’s free HMAC Generator computes a keyed hash of any message with HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 or HMAC-SHA512. Enter the message and your secret key, pick an algorithm, and the signature appears as lowercase hex and Base64 as you type, ready to paste into a request header, a test case or a debugging session, or to check against a signature you received.
The calculation runs in your browser using the built-in Web Crypto API, the standard cryptography interface that modern browsers provide to web pages. Your message and secret key are never uploaded, stored or logged, so you can check a signature during development without handing the key to a third-party server.
How to Use the HMAC Generator
- 1
Enter the message
Type or paste the exact message you want to sign into the Message box, such as a raw webhook body or a canonical request string. Every character counts, including spaces and line breaks.
- 2
Enter the secret key
Type or paste the shared secret into the Secret Key field. Leave Key format on Text for a plain secret, or choose Hex or Base64 if your provider gives the key in one of those encodings.
- 3
Choose the algorithm
Pick HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 or HMAC-SHA512 from the Algorithm menu. HMAC-SHA256 is selected by default.
- 4
Copy or verify
The signature appears as you type, in both lowercase hex and Base64, each with a Copy button. To check a signature you received, paste it into the Verify box and the tool says whether it matches.
There is no sign-up and no limit on how many HMACs you compute.
What Is HMAC and How Does It Work?
An HMAC (hash-based message authentication code, RFC 2104) answers two questions at once: was this message changed in transit, and did it come from someone who holds the secret key? A plain hash such as the one from the SHA-256 hash generator only answers the first, because anyone can recompute it. An HMAC folds the key into the hash, so a forger who alters the message cannot produce a matching value.
The construction is HMAC(K, m) = H((K′ ⊕ opad) ‖ H((K′ ⊕ ipad) ‖ m)). The key K is padded to the hash’s block size (64 bytes for SHA-1 and SHA-256, 128 bytes for SHA-384 and SHA-512) to give K′, after first being hashed if it is longer than a block. It is XORed with two fixed patterns, the inner pad (bytes of 0x36) and the outer pad (bytes of 0x5c), and the message is hashed twice. This nested design is what protects HMAC from the length-extension attacks that affect a naive hash of key plus message.
Worked example
Take the message The quick brown fox jumps over the lazy dog and the secret key key. The results are:
| Calculation | Hex output |
|---|---|
| Plain SHA-256 (no key) | d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592 |
| HMAC-SHA256 | f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8 |
| HMAC-SHA1 | de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9 |
Paste those inputs into the tool to confirm it matches. Change a single letter of the message or the key and the HMAC changes completely, which is exactly the property a receiver relies on when checking a signature.
HMAC-SHA1 vs HMAC-SHA256 vs HMAC-SHA512
| Algorithm | Output | Hex length | Block size |
|---|---|---|---|
| HMAC-SHA1 | 160 bits | 40 characters | 64 bytes |
| HMAC-SHA256 | 256 bits | 64 characters | 64 bytes |
| HMAC-SHA384 | 384 bits | 96 characters | 128 bytes |
| HMAC-SHA512 | 512 bits | 128 characters | 128 bytes |
The right choice is almost always the one the other side expects, because both parties must use the same algorithm to get the same value. HMAC-SHA256 is the usual default for webhooks, API request signing and JSON Web Tokens: the HS256 algorithm you see in a token’s header in the JWT decoder is HMAC-SHA256. HMAC-SHA1 remains in older integrations and in one-time passcodes; the TOTP generator on this site uses HMAC-SHA1 to turn a shared secret and the current time into a six-digit code. The collision weaknesses found in SHA-1 do not directly break HMAC-SHA1, but SHA-256 or stronger is the better pick for new work.
Verifying Webhook and API Signatures
Most webhook providers sign each delivery by computing an HMAC of the request body with a secret you share, then sending it in a header. To debug a failing check, copy the raw body exactly as received, paste it into the Message box with your endpoint secret as the key, and compare the result with the header value. Some schemes sign more than the body, for example a timestamp joined to the body with a dot, so build the message exactly as the provider’s documentation describes.
Mismatches nearly always come from the input, not the math. Parsing and re-serializing JSON changes spacing and key order, a trailing newline adds a byte, and a header may carry a prefix such as sha256= before the hex. Paste the header value into the Verify box: the prefix is ignored and hex or Base64 both work. If the provider’s secret is itself encoded, set Key format to Hex or Base64 so it is decoded first. In production code, compare signatures with a constant-time function rather than a simple string equality check.
HMAC keys should be long and random. The password generator can create a 32 to 64 character secret in seconds. Keep in mind that HMAC is for signing messages, not for storing passwords; password storage needs a deliberately slow, salted algorithm such as the one in the bcrypt generator. And if you find an unlabeled digest in a log and want to know whether it is a 64-character SHA-256 value or something else, the hash identifier lists likely algorithms by format.
Common uses
- Checking a webhook signature while building or debugging an endpoint
- Producing the expected value for a unit test of your own signing code
- Comparing an HMAC from a backend service or script against an independent result
- Signing a canonical request string when testing an API that uses HMAC authentication
- Learning how keyed hashing differs from plain hashing by trying different keys
For more hashing, encoding and token utilities, browse all security tools on The Tools Kit.
HMAC terms explained
| Term | What it means here |
|---|---|
| HMAC | Hash-based message authentication code: a hash of a message mixed with a secret key, defined in RFC 2104 |
| Secret key | The value shared only between sender and receiver; without it nobody can produce a matching HMAC |
| Digest | The fixed-length output of the hash function; here it is shown as lowercase hexadecimal and as Base64 |
| Block size | The chunk size the hash works on: 64 bytes for SHA-1 and SHA-256, 128 bytes for SHA-384 and SHA-512. Longer keys are hashed down first |
| Signature header | The HTTP header in which an API or webhook sends its HMAC so the receiver can recompute and compare it |
| Constant-time comparison | Checking two signatures without stopping at the first mismatched character, so timing does not leak the correct value |
Frequently Asked Questions
HMAC stands for hash-based message authentication code. It runs a hash function such as SHA-256 over a message combined with a secret key, producing a value that proves the message was not changed and came from someone who knows the key. It is defined in RFC 2104.
Paste the message, enter the secret key and leave the Algorithm menu on HMAC-SHA256 (the default). The 64-character hex result and its Base64 form appear below as you type, each with a Copy button.
A plain SHA-256 hash depends only on the message, so anyone can recompute it. An HMAC also depends on a secret key, so only someone who holds the key can create or verify it. For example, the SHA-256 of "The quick brown fox jumps over the lazy dog" starts d7a8fbb3, while its HMAC-SHA256 with the key "key" starts f7bc83f4.
No. The HMAC is computed in your browser with the built-in Web Crypto API. The message and key are not uploaded, saved or logged, and they are gone when you close or reload the page.
Use whatever the system you are integrating with specifies, since the receiver must use the same algorithm. For new designs HMAC-SHA256 is the common default. HMAC-SHA384 and HMAC-SHA512 give longer outputs, and HMAC-SHA1 is mainly kept for older integrations.
The result is shown as lowercase hex, two characters per byte: 40 characters for HMAC-SHA1, 64 for HMAC-SHA256, 96 for HMAC-SHA384 and 128 for HMAC-SHA512. The length depends only on the algorithm, not on the message or key length.
Yes. The tool shows both. Hex and Base64 are two ways of writing the same bytes: the HMAC-SHA256 of "The quick brown fox jumps over the lazy dog" with the key "key" is f7bc83f4… in hex and 97yD9DBT… in Base64. Use whichever form your provider sends.
Yes. Set Key format to Hex or Base64 and the key is decoded into raw bytes before signing; URL-safe Base64 and missing padding are accepted. Leave it on Text when the provider means the secret string itself. Check their documentation, because the same characters give a different HMAC in each mode.
Paste the raw request body into Message, your endpoint secret into Secret Key, and the signature from the header into the Verify box. Hex or Base64 both work, and a sha256= prefix is ignored. The tool shows Match or No match, comparing the bytes rather than the text.
The usual causes are a different message (a re-serialized JSON body, a missing timestamp prefix, an extra space or trailing newline), a different key (wrong environment, or a key that should have been decoded first), a different algorithm, or comparing hex against Base64. Sign the exact raw bytes the sender signed.
Nothing is computed until the Secret Key field has something in it, or while a hex or Base64 key cannot be decoded. The message itself may be empty; the HMAC of an empty message is still a valid value.
Yes. The signature is recomputed as you type, and whenever you change the key format or algorithm, so the result always matches what is on screen.
No. Like the hash it is built on, an HMAC is one-way. It is meant for verifying a message you already have, not for hiding or recovering it. To keep a message secret it must be encrypted, which is a separate step.
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026
How do you generate an HMAC hash?
To generate an HMAC, enter the message, enter the secret key, choose HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, or HMAC-SHA512, and the keyed hash is returned as lowercase hex and Base64. The computation uses the browser's built-in Web Crypto API, so neither the message nor the secret key is ever sent to a server.
What is the difference between HMAC and a plain SHA-256 hash?
A plain SHA-256 hash depends only on the message, so anyone can recompute it. An HMAC mixes in a secret key, so only someone holding that key can produce or verify the value. That makes HMAC-SHA256 suitable for signing webhooks, API requests, and tokens, where a plain hash offers no authentication at all.