HMAC Generator

HMAC answers “did a key holder send these exact bytes?”

A Hash-based Message Authentication Code combines a shared secret with a cryptographic hash in a standardized inner-and-outer construction. Given the same key, message bytes, and hash algorithm, it returns the same authentication tag. A recipient who possesses that key recalculates the tag and compares it with the supplied value.

This provides integrity and symmetric authentication: modification is detectable, and a party without the key should not be able to forge a valid tag. It does not encrypt the message, conceal the secret, or prove which of two key holders acted. Because either holder can generate tags, HMAC is not a public digital signature and does not provide non-repudiation.

The HMAC generator on this page accepts a Secret Key and Text Message as UTF-8 text. It supports HMAC-SHA-256, HMAC-SHA-512, HMAC-SHA-1, and HMAC-MD5, with lowercase hex, uppercase hex, or standard Base64 output. Results update on every input or selection change. Clear removes both fields; Copy places the current tag on the clipboard.

Use this browser implementation for known-answer tests, webhook debugging with non-production fixtures, and output-format checks. Do not paste a live webhook secret, API signing key, or customer payload into a third-party page. In production, calculate and verify HMAC inside your server or trusted runtime, with secrets loaded from a secret manager and never exposed to client JavaScript.

What actually gets authenticated

The key field is encoded with UTF-8. Entering 736563726574 therefore uses twelve ASCII bytes, not the six bytes represented by that hex string. Likewise, Base64-looking text is not decoded. If a protocol provides the key as hex or Base64, decode it before importing it in production or use a test tool that explicitly supports that representation.

The message is also UTF-8. Newlines, trailing spaces, Unicode normalization, JSON formatting, and percent encoding all alter the bytes and therefore the HMAC. Authenticating parsed and reserialized JSON commonly fails because property order or whitespace changes. Webhook specifications usually require the raw request body exactly as received.

Output format comes after computation. A 32-byte HMAC-SHA-256 tag appears as 64 lowercase hex characters, 64 uppercase hex characters, or 44 characters in padded Base64. Changing the display does not change the tag bytes. Base64url is a distinct representation and is not offered here.

Verify an HMAC-SHA256 integration methodically

Start with a published test vector rather than a live request. For a simple cross-language fixture, use the UTF-8 key key and message The quick brown fox jumps over the lazy dog. HMAC-SHA-256 in lowercase hex should be:

f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8

If your application disagrees, record the key representation, an escaped message, message byte length, algorithm name, and tag encoding. Never print a production key while diagnosing. Compare decoded tag bytes, not visual casing.

For webhook verification, a robust flow is:

1. Read the raw body bytes before JSON parsing or middleware mutation.
2. Parse the provider’s signature header according to its documented version and encoding.
3. Include any required timestamp, request target, or header fields in the exact canonical order.
4. Compute HMAC with the endpoint’s secret and specified algorithm.
5. Decode the received tag and compare equal-length byte arrays in constant time.
6. Reject stale timestamps and record an event identifier to limit replay.
7. Only after successful verification, parse and process the payload.

HMAC alone does not stop replay: a captured valid message and tag remain valid unless the signed content includes freshness and the verifier enforces it. A timestamp tolerance, nonce, sequence number, or idempotency record addresses that separate problem.

Algorithm choice and key handling

Choose SHA-256 for a new ordinary integration unless a reviewed standard requires something else. SHA-512 has a larger native output and different block size; it is not a drop-in textual replacement. Both peers must use the same algorithm and representation.

SHA-1 and MD5 are offered for compatibility testing. Their collision weaknesses do not translate identically to HMAC forgery, but legacy primitives carry ecosystem risk and reduced margins. Do not select HMAC-MD5 or HMAC-SHA-1 for a new protocol merely because this tool can compute them. Follow the protocol when interoperability is mandatory, then plan a versioned migration.

Use a randomly generated secret with enough entropy, preferably at least 256 bits for HMAC-SHA-256. Human words, UUIDs chosen for identification, timestamps, and source-code constants are poor signing keys. HMAC internally handles keys longer or shorter than the hash block size, so manually padding, truncating, or pre-hashing a key changes the scheme and usually breaks compatibility.

Separate keys by purpose and environment. A test webhook secret must not sign production API requests. Rotation works best with key identifiers: sign with the current key, temporarily verify against current and previous keys, and retire the old one after the delivery window. Scope access so services that only verify do not automatically gain unrelated credentials, although symmetric HMAC verification inherently requires secret material.

Why hash(secret + message) is not HMAC

HMAC normalizes the key to the hash block size, XORs it with ipad (0x36) for an inner hash, then with opad (0x5c) for an outer hash. In shorthand:

H((K' xor opad) || H((K' xor ipad) || message))

This analyzed construction avoids weaknesses of naive concatenation, including length-extension attacks affecting Merkle-Damgård hashes. SHA256(key || message), SHA256(message || key), and HMAC-SHA-256 produce different outputs and are not interchangeable. Do not invent a custom “signed hash” when standard HMAC libraries exist.

An ordinary hash has no secret and therefore cannot authenticate an attacker-controlled message. Encryption serves confidentiality and requires a nonce or IV, mode, and key-management design; it does not automatically authenticate unless using an authenticated mode such as AES-GCM. Encoding as hex or Base64 is reversible formatting with no security property.

Failure patterns worth testing

Canonicalization causes most integration tickets. Test an empty body, one trailing LF, CRLF, a multibyte character, JSON with reordered fields, and a payload containing escaped slashes. Check whether the provider signs compressed bytes, decompressed bytes, or an envelope. Confirm whether a header includes a prefix such as sha256= that must be removed before hex decoding.

Avoid ordinary === tag comparison in production. Early-exit comparisons can reveal matching prefixes through timing, especially across repeated local requests. Use crypto.timingSafeEqual or the platform equivalent after validating decoded lengths. A length mismatch should fail without attempting a comparison that throws.

Do not accept whichever algorithm appears in an untrusted header unless the protocol safely binds and restricts it. Algorithm confusion and downgrade behavior can turn compatibility code into a bypass. Configure expected versions server-side.

Finally, a valid HMAC says the signed bytes came from some holder of the shared key. It does not certify that the content is authorized for the current user, semantically valid, harmless, or unique. Continue normal schema validation, authorization, replay defense, and business checks after signature verification.

Test empty fields deliberately

The component clears its calculated output only when both Secret Key and Text Message are empty. An empty message with a nonempty key and a nonempty message with an empty key are still valid HMAC inputs and produce tags. This is cryptographically legitimate, but it can surprise someone who expects blank form controls to disable generation. Include both cases in integration fixtures because middleware may represent a missing body, empty body, and zero-length decoded body differently. The Clear action empties both fields together; after using it, restore the exact test key representation rather than assuming a visually blank key matches a protocol default.

FAQ

Why does my online HMAC generator result differ from code?

The common causes are key decoding, UTF-8 versus another encoding, altered request bytes, a missing signed timestamp, Base64 versus Base64url, and comparing HMAC with a plain hash. Inspect byte lengths and use a known vector first.

Can I recover the secret from an HMAC tag?

Not through a reverse operation. A weak secret can still be guessed offline by computing candidate tags for a known message, which is why keys need high entropy.

Is HMAC-SHA256 a digital signature?

It is often casually called a signature in API headers, but cryptographically it is a symmetric MAC. Anyone able to verify also holds the secret needed to forge.

Should the key be longer than the message?

No. Key strength depends on entropy, not on matching message length. Generate and manage it according to the selected algorithm and protocol.

Does HMAC protect webhook confidentiality?

No. The payload remains readable. Use TLS in transit and appropriate encryption at rest; keep HMAC for authenticity and integrity.