Complete HMAC-SHA Algorithm Guide

HMAC (Hash-based Message Authentication Code) is a standard method for constructing message authentication codes, proposed by Hugo Krawczyk at IBM in 1996 and published as RFC 2104 in 1997.

It achieves two security goals simultaneously:

• Data integrity: Any tampering with a message in transit will cause the HMAC to fail verification.
• Sender authentication: only parties holding the pre-shared secret key can produce a matching authentication code.

A common misconception is to think of HMAC as simply "hashing with a key". In reality, it is more sophisticated: the key is XOR'd with two different padding constants — ipad (0x36) and opad (0x5C) — and two rounds of hashing are performed. This design elegantly avoids length-extension attacks and other weaknesses of naive "key || message" constructions.

With our HMAC-SHA tool, you simply enter the message and key — all padding details are handled automatically.

The core HMAC formula is as follows (where H is the hash function such as SHA-256, K is the secret key, m is the message, and || denotes byte concatenation):

HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m))

The entire process breaks into three steps:

• Key preparation: If K is longer than the hash function's block size (e.g., 64 bytes for SHA-256), it is first hashed down. If K is shorter than the block size, it is right-padded with 0x00 bytes to the block size.
• Inner hash: XOR the prepared key with ipad (0x36 per byte), concatenate it with message m, and hash once to obtain the inner digest.
• Outer hash: XOR the prepared key with opad (0x5C per byte), concatenate the inner digest, and hash again. The result is the final HMAC.

Because the hash function is pluggable, HMAC naturally supports many algorithms:

• HMAC-SHA1: 40 hex characters (160-bit) output. Compatible with older systems but collision strength is no longer sufficient for new designs.
• HMAC-SHA256: 64 hex characters (256-bit). The current industry default, and the foundation of JWT's default HS256 algorithm.
• HMAC-SHA384 / HMAC-SHA512: 96 / 128 hex characters. Provide longer digests and higher security margins for systems with strict security requirements.
• HMAC-SHA3-256 / HMAC-SHA3-512: Based on the Keccak sponge construction, structurally different from SHA-2. Used where "algorithm diversity" is needed.
• HMAC-MD5: 32 hex characters. Should only be used for backward compatibility and non-security scenarios.

In our tool, you can switch between all 7 algorithms in the same interface to quickly compare outputs across them.

The raw output of HMAC is a fixed-length binary byte array. In real projects, it is typically passed around in one of three printable formats:

• Hexadecimal lowercase: Each byte represented as two lowercase hex characters (e.g., f7bc83f4…). This is the most common default. Node.js's crypto.createHmac().digest("hex"), Python's hmac.new().hexdigest(), and openssl dgst -sha256 -hmac all output lowercase by default.
• Hexadecimal uppercase: Matches lowercase byte-for-byte but uses uppercase characters. Common in Java's javax.xml.bind.DatatypeConverter, some .NET APIs, and older protocol specifications. A case-sensitive string comparison between lowercase and uppercase will fail, even though the numeric value is identical.
• Base64 encoding: The raw byte array is Base64-encoded into a more compact string (44 characters for SHA-256). Widely used in JWT signatures, OAuth 1.0a, AWS Signature v4, and HTTP request signing.

A very common debugging trap is "the server outputs Base64 but the client compares against hex" or vice versa. Converting both to the same representation is the very first troubleshooting step. Our tool produces all three outputs in a single input, letting you directly compare against your server-side implementation.

HMAC appears in virtually every system concerned with "identity + integrity". Here are 7 typical real-world scenarios:

• REST API request signing: The client runs HMAC-SHA256 over request parameters, a timestamp, and a nonce together with the secret key. The server replays the same computation and compares to verify that the request has not been tampered with in transit.
• Webhook callback verification: Platforms like GitHub, Stripe, Slack, and DingTalk carry HMAC digests in request headers such as X-Hub-Signature-256 or stripe-signature. Receivers verify these to confirm events originate from the real platform.
• JWT signing algorithms HS256 / HS384 / HS512: These HMAC-family algorithms use a shared secret to sign the base64url(header).base64url(payload) portion of a JSON Web Token; the receiver verifies with the same key.
• OAuth 1.0a signing: In the older OAuth 1.0a specification, HMAC-SHA1 is the most common signing method used to authenticate request parameters.
• AWS Signature v4 / Aliyun API signing: Cloud vendors' request signing mechanisms typically use multi-layer HMAC-SHA256 over canonicalized request strings and dates to verify the caller's identity.
• Keyed file integrity verification: In security-sensitive distribution systems, the server can sign each file with HMAC. Receivers verify with the pre-shared key, adding an identity layer on top of a plain checksum.
• CSRF tokens / short-link signatures / one-time passwords: Binding a timestamp or sequence number to a secret key via HMAC prevents forgery in CSRF tokens, short-link signatures, and OTP schemes.

For the scenarios above, using an online HMAC-SHA tool for local reproduction quickly tells you whether a mismatch comes from the client-side computation or the server-side verification — dramatically shortening integration time.

Understanding the differences between schemes helps you make the right architectural decisions:

• Plain SHA hash: Guarantees data integrity only, no authentication. Anyone can compute the same hash. Suitable for public file checksums.
• HMAC-SHA: Provides both integrity and authentication based on a shared symmetric key. Ideal for server-to-server calls, API signing, Webhooks, and other scenarios with pre-shared keys.
• JWT (HS256 / HS384 / HS512): This is actually HMAC-SHA in a standardized format — the message is normalized as base64url(header).base64url(payload), and the signature is appended as Base64URL. Convenient for carrying structured claims.
• JWT (RS256 / ES256 and other asymmetric signatures): Signs with a private key and verifies with the corresponding public key. Avoids the risks of sharing a single key across multiple parties. Suitable for multi-tenant and OAuth2 open systems.
• Authenticated encryption (e.g., AES-GCM, ChaCha20-Poly1305): Use AEAD schemes when you need to encrypt messages in addition to authenticating them.

Rules of thumb: if two parties already share a secret key and the message is transmitted in plaintext → use HMAC-SHA256; if the message needs to carry verifiable claims for third parties → use JWT (HS256 or RS256); if signers and verifiers must use different keys → use asymmetric signatures; if the message must also be kept confidential → use AEAD encryption.

To verify a plain SHA hash, use our SHA tool; for HMAC results, use our HMAC-SHA tool.

Although HMAC is simple on paper, tiny implementation differences frequently cause signatures to fail during integration. Here are 6 practical troubleshooting tips:

• Unify character encoding: HMAC operates on bytes. The same string produces different bytes when encoded as UTF-8, UTF-16, or GBK — so the HMAC will differ. Always standardize on UTF-8.
• Unify newline and whitespace handling: Multi-line messages use on Windows and on Linux / macOS. If the client and server disagree on line endings, HMAC results will not match.
• Normalize parameter order: API signing typically requires parameters to be sorted by key before concatenation. Strictly follow the same ordering rule, and pay attention to case sensitivity of parameter names.
• Hex vs Base64: pick a consistent output format: If the spec requires Base64, do not return the hex string, and vice versa. Our tool outputs both formats simultaneously for comparison.
• Does the key need hashing or Base64 decoding first?: Some platforms expect the key to be Base64-decoded before being fed into HMAC; others use the key as string bytes directly. Read the documentation carefully.
• Timestamps, nonces, and replay protection: Signatures usually include timestamps and nonces. A large time drift or using the wrong unit (seconds vs milliseconds) will cause verification to fail. During debugging, fix the timestamp and nonce to constant values first to verify the core algorithm.

Adding these steps to your team's integration checklist can dramatically reduce time spent on "why is my signature always wrong" questions.

When you need to compute HMAC with sensitive keys (e.g., production API secrets), be extremely careful about "convenient-looking" online tools. The critical question is: does that tool upload your key to its server? Does it log requests?

Our HMAC-SHA tool is built on the browser's built-in Web Crypto API and CryptoJS. All computation happens entirely inside your browser. There are no HTTP upload requests for keys or messages, and no input is persisted to localStorage.

Even so, here are additional security recommendations:

• Use private browsing mode for sensitive keys: This ensures no traces remain in browser history, autofill, or extensions when you close the window.
• Never enter production secrets on shared or company-monitored devices: Keyloggers and screen-capture software may bypass browser-level protections.
• Avoid committing real secrets to public docs or Git repos: Use temporary test keys even for debugging.
• Rotate keys periodically: Immediately rotate keys on the server side if a leak is suspected.
• Never substitute plain SHA for HMAC as authentication: SHA guarantees integrity only, not origin. HMAC provides both.

Choosing an online HMAC tool that processes locally, keeps no logs, and uploads nothing lets you stay convenient while retaining full control of your keys.