Sign a message with a secret key using HMAC-SHA-256, SHA-1, SHA-384 or SHA-512. Key as text, hex or Base64.
To generate an HMAC, enter a message and a secret key, pick SHA-1, SHA-256, SHA-384 or SHA-512, and the tool shows the keyed hash of the message in hex or Base64. HMAC is defined in RFC 2104 as H((K' xor opad) followed by H((K' xor ipad) followed by the message)), where H is the hash function, ipad is the byte 0x36 repeated, opad is the byte 0x5c repeated, and K' is the key padded with zeros to the hash's block size, or hashed first if it is longer. The block size is 64 bytes for SHA-1 and SHA-256 and 128 bytes for SHA-384 and SHA-512. The page opens with test case 2 of RFC 4231: the key Jefe and the message what do ya want for nothing? give HMAC-SHA-256 5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843.
A text key or message is encoded as UTF-8 before it is used, so é is two bytes. Choose Hex when your key is written as hexadecimal, such as a 32-byte key of 64 hex digits; spaces, colons and a leading 0x are ignored. Choose Base64 for a Base64 or Base64 URL key. If you leave a hex or Base64 key on Text, its characters are used as text, which gives a different answer; this is the most common reason an HMAC does not match another system. The result card shows the key and message sizes in bytes so you can compare them with the other side. A line break at the end of a text key counts as part of the key, and the tool warns you. An empty key is accepted. The output is hex in lower case (40, 64, 96 or 128 digits for SHA-1, SHA-256, SHA-384 and SHA-512), Base64 with padding, or Base64 URL without padding.
To reproduce a webhook signature that is the HMAC-SHA-256 of the raw request body, paste the exact body as the message and the shared secret as the key, then compare the hex or Base64 result with the one you received. The signature of a JWT that uses HS256 is the HMAC-SHA-256 of the text header.payload, written in Base64 URL: paste the two Base64 URL parts joined by a dot as the message, choose Base64 URL output, and compare with the third part. The tool computes a tag. It does not verify one against a received value, and when you compare tags in your own code use a constant-time comparison.
The tool is checked against the published test vectors: the seven test cases of RFC 4231 for SHA-256, SHA-384 and SHA-512, and the seven test cases of RFC 2202 for SHA-1, including keys longer than the block size. HMAC-MD5 is not offered because the browser's built-in crypto has no MD5. It needs a browser with Web Crypto on an https page. Text up to 1,000,000 characters is accepted per box. The work happens in your browser; the message and key are not uploaded or stored, only your option choices are remembered. Use a test key here, not a production secret.
Type the message, type the secret key, leave the hash function on SHA-256 and copy the result. With the key Jefe and the message what do ya want for nothing? the answer is 5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843, the value in RFC 4231.
A plain SHA-256 hash needs no key, so anyone can recompute it. An HMAC mixes in a secret key, so only someone who has the key can produce or check it. Both give 32 bytes, which is 64 hex digits, for SHA-256.
Set Key is to Hex or Base64. A 32-byte key written as 64 hex digits then counts as 32 bytes. Left on Text, the same 64 characters would count as 64 bytes of text and give a different HMAC.
Compare the byte counts in the result card first. The usual causes are a hex or Base64 key read as text, a line break at the end of the message or key, JSON whitespace that differs from the body that was signed, and a different hash function.
Paste header.payload, the first two Base64 URL parts joined by a dot, as the message. Enter the secret as the key, pick SHA-256 and Base64 URL output. The result should equal the third part of the token.
No. The message and key are processed in your browser, in this tab, and no server receives them. Your option choices are saved in this browser; the message and key are not.