HMAC-SHA Message Authentication Tool - Online HMAC-SHA1, HMAC-SHA256, and HMAC-SHA512 Calculation

HMAC was proposed by Hugo Krawczyk at IBM in 1996 and published as RFC 2104 in 1997. It is not a new hash function itself — rather, it is a "wrapper" that works on top of any standard hash function (SHA-256, SHA-512, SHA-3, etc.). The secret key is XOR'd with two different padding constants — ipad (0x36) and opad (0x5C) — and the message is hashed twice with these keyed pads in between, producing a fixed-length "message authentication code".

This design is not arbitrary: earlier naive approaches such as H(key || message) were vulnerable to length-extension attacks. HMAC, in contrast, has been mathematically proven secure as long as its underlying hash function is secure.

Compared to plain SHA hashing, the crucial difference is the "key". Anyone with access to the data can compute the same SHA value — so SHA only proves "the data was not changed". HMAC requires the pre-shared secret key to both generate and verify. It therefore proves both "the data was not changed" and "the data definitely came from a party who holds the key". These two guarantees together are essential in real-world scenarios such as API calls, Webhooks, payment callbacks, and more.

This tool supports 7 of the most common hash algorithm combinations: HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, HMAC-SHA3-256, HMAC-SHA3-512, and the backward-compatible HMAC-MD5.

HMAC-SHA256 is the de-facto industry default: it underlies the HS256 algorithm in JWT, and is the standard signing method used by AWS Signature v4, GitHub Webhooks, Stripe signatures, Slack Events API, and many other services. HMAC-SHA512 provides a longer digest and a higher security margin, suited for internal systems with stricter cryptographic requirements. HMAC-SHA1 and HMAC-MD5 are kept primarily for legacy compatibility.

Regardless of which algorithm you choose, the tool always outputs all three standard representations simultaneously: hex lowercase (the default, matching hexdigest in most languages), hex uppercase (commonly seen in Java and some .NET APIs), and Base64 (used in JWT, OAuth, and HTTP signature headers). One input, three ready-to-paste outputs — particularly convenient during integration and troubleshooting.

This tool is built on the browser's built-in Web Crypto API and the battle-tested CryptoJS library. Every computation happens entirely inside your browser: keys, messages, and results are never uploaded to any server via HTTP requests, and nothing is written to localStorage or cookies. This is especially critical when you are dealing with production API secrets, payment keys, or other sensitive information — never hand your keys to a tool that "uploads to the cloud for processing".

Beyond local computation, the tool also offers a full developer toolbox: random key generation (one-click to generate a 32-byte test key), one-click message paste (read the content to be signed directly from the clipboard), per-result copy (copy each format independently), and TXT download (save the full output for documentation). These small features add up to significant time savings during API integration, Webhook callback verification, manual JWT validation, and debugging signature mismatches between client and server implementations.

If you would like to dive deeper — into the RFC 2104 principles, 7 real-world use cases, how HMAC compares to plain SHA and JWT, or 6 practical troubleshooting tips — read the full technical walkthrough in the HMAC-SHA Algorithm Guide.