Advanced HMAC Generator

HMAC (Hash-based Message Authentication Code) proves that a message came from someone who knows a shared secret key and was not changed on the way. It is defined as HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)): the key is mixed in twice, in an inner and an outer hash, using two fixed padding constants. It is used to sign API requests, verify webhooks, protect cookies and sessions, and in JWTs (HS256, HS384, HS512). HMAC authenticates a message; it does not encrypt it.

Because plain hashes like SHA-256 and SHA-512 are vulnerable to length-extension attacks: given SHA-256(key + message) and the message length, an attacker can compute a valid hash for the message plus extra data without knowing the key. HMAC's nested structure is designed to prevent exactly that, which is why you should always use HMAC rather than inventing your own keyed hash.

HMAC-SHA-256 is the usual default and what most services expect. SHA-384 and SHA-512 give longer outputs and are used where a service specifies them. HMAC-SHA-1 is still considered secure, because the collision attacks that broke SHA-1 do not apply to HMAC, but it is best avoided in new designs and kept only for compatibility. MD5 is not offered. Always use the algorithm the other side specifies, since different algorithms give completely different results.

Use a random key at least as long as the hash output: 32 bytes for SHA-256, 48 for SHA-384 and 64 for SHA-512 (RFC 2104). Longer keys do not add strength beyond the hash size, because a key longer than the hash's block size is hashed first. A key made from a human-chosen password is only as strong as that password, so use the Generate random key button, which fills the key with random bytes from the Web Crypto API, and store the key in a secret manager rather than in code.

The result depends on exact bytes, so the most common causes are: the key being interpreted differently (as text instead of hex or Base64, or the other way round), a trailing newline or different line endings in the message, a different text encoding (this tool uses UTF-8), JSON that was reformatted before signing, a different algorithm, or comparing a hex result with a Base64 one. Set the key and message formats to match how the other side treats them, and try the RFC 4231 example button to confirm the tool itself agrees with the standard.

Enter the same key and the exact message body, then paste the signature you received into the verify box. It accepts hex or Base64 (standard or URL-safe) and ignores a leading sha256=-style prefix, as used by GitHub webhooks. The comparison is done with the browser's constant-time verify function. In your own code, always compare signatures with a constant-time function rather than ==, and check a timestamp or nonce so an old signed message cannot be replayed.

Everything runs in your browser with the Web Crypto API, the page's content security policy blocks outgoing network requests, and nothing is saved: there is no history and no local storage, and the key box hides your key by default. Even so, the safest habit is to test with throwaway keys and never paste a production secret into any website. Files are limited to 256 MB because the browser's HMAC function needs the whole file in memory.

The tool shows a warning and disables itself rather than falling back to weaker, hand-written cryptography. The Web Crypto API needs a modern browser and a secure (HTTPS) page. One more limit to know: the browser's HMAC function does not accept an empty key, so the tool asks for a key with at least one byte.