HMAC Generator

Introduction

A signed webhook, callback, or API request is judged by bytes, not by how the text looks on screen. One service may sign a raw JSON body, another may sign a canonical request string, and a third may prepend a timestamp before the body. If the receiver repeats the calculation over even one different byte, the authentication code changes completely.

A hash-based message authentication code, usually shortened to HMAC, is a keyed integrity check. The sender and receiver share a secret key. The sender combines that key with the message and a cryptographic hash function, then sends the resulting digest text as a header, token, or test vector. The receiver repeats the same calculation with its copy of the secret. A byte-for-byte match is evidence that the signed content was not changed and that the signer knew the shared key.

HMAC is easy to confuse with nearby security tools. A plain hash such as SHA-256 can detect accidental changes, but anyone can recompute it. Encryption hides content, but it does not by itself prove who prepared the content. A public-key digital signature uses separate private and public keys. HMAC is symmetric: the same shared secret gives both sides the ability to create valid codes, which makes secret handling as important as the hash choice.

Signed bytes

The exact message byte sequence after text encoding, byte decoding, and any documented newline treatment.

Shared secret

The key known by the signer and verifier. Anyone who learns it can create valid HMAC values.

Hash family

The digest algorithm inside the HMAC construction, such as SHA-256, SHA-512, SHA-1, RIPEMD-160, or MD5.

Digest text

The raw HMAC bytes displayed as lowercase hex, uppercase hex, Base64, or Base64URL.

Header prefix

Provider text such as sha256=, sha1=, or v1= placed before the digest after the HMAC has already been calculated.

Most HMAC debugging comes down to matching the signing recipe exactly. Webhook providers commonly use SHA-256 with a prefix such as sha256=. Some older services still publish SHA-1, RIPEMD-160, or MD5 examples. Token and URL workflows may prefer Base64URL because it avoids +, /, and padding characters that need escaping. None of those display choices repair a mismatch caused by signing the wrong body, trimming the wrong newline, or decoding the secret in the wrong encoding.

A matching HMAC is a narrow result. It confirms that the same message, secret, hash family, and byte treatment produced the same authentication code. It does not make the message confidential, prove that the account is trustworthy, or remove the need to protect and rotate shared secrets.

How to Use This Tool:

Use the generator as a byte-for-byte signing workspace: set the message and secret encodings first, match the verifier's algorithm and display format, then compare the generated value against the expected header or digest.

1. Enter the exact content in Message to sign, or load a local TXT, JSON, CSV, or log file with Browse text. The local text-file limit is 512 KB, and whitespace is part of the signed message.
2. Choose Message encoding. Use UTF-8 text for raw webhook bodies and canonical strings. Use Hex bytes, Base64 bytes, or Base64URL bytes only when the message box already contains encoded bytes.
3. Enter Secret key and choose Key encoding. Generate test key creates a local 32-byte Base64URL test secret for examples and test vectors, not a production secret-management workflow.
4. Set Algorithm to the verifier's exact HMAC hash. The supported options are HMAC-SHA-256, SHA-512, SHA-384, SHA-224, SHA-1, RIPEMD-160, and MD5.
5. Set Output format and Header prefix. The prefix is added to the copied header value after digest generation, so switching from sha256= to v1= does not change the raw digest bytes.
6. Paste an optional Expected signature. Leave Expected format on Auto detect for ordinary provider headers, or pin Hex, Base64, or Base64URL when the expected value is ambiguous.
7. Open Advanced only when the signing specification names a text treatment rule. Exact text signs the message as entered, Trim one final newline removes one trailing line break, and Normalize CRLF to LF changes Windows-style line endings before signing.
8. Copy the header or digest only after the summary shows a ready signature or a successful match. If the summary reports an input issue, fix the missing secret, malformed byte encoding, invalid expected value, or oversized file before copying.

Interpreting Results:

The top signature field shows the current generated value. Copy header includes the selected prefix when one is active, while Copy digest copies only the digest text. The HMAC Signature tab repeats the current artifact in a compact text form.

Signature Ledger records the generated header, raw digest, algorithm, key encoding, message size, prefix choice, and security posture. Verification Checks focuses on expected-value parsing, key length, message treatment, prefix fit, and secret handling. Algorithm Outputs recomputes the same parsed message and secret across every supported algorithm, which helps when a provider example omits the hash family or labels it incorrectly.

A match should not be overread. It proves reproducibility for the chosen inputs. It does not show that the shared secret has never leaked, that the sender is allowed to perform the requested action, or that the message content is safe to process.

Technical Details:

HMAC is a two-pass keyed hash construction. The secret key is adjusted to the hash function's block size, mixed with an inner pad, hashed with the message, then mixed with an outer pad and hashed again. This structure avoids the weaknesses of simply concatenating a secret with a message and hashing the result.

The important separation is between bytes and text. The message and secret must first become byte arrays. The hash family then produces raw HMAC bytes. Only after that does formatting turn those bytes into lowercase hex, uppercase hex, Base64, or Base64URL text. A prefix such as sha256= is outside the HMAC calculation.

Formula Core

The standard HMAC construction uses an inner hash result as input to an outer hash.

K is the shared secret, m is the exact message byte sequence, H is the selected hash function, and K0 is the key after block-size adjustment. The fixed pad byte patterns are known as ipad and opad. Hex, Base64, Base64URL, and header prefixes are display conventions applied after the HMAC bytes exist.

Transformation Core

Expected signatures are safer to compare as decoded bytes than as raw strings. Prefix text such as x-hub-signature-256:, sha256=, ripemd160=, md5=, and version-style prefixes such as v1= can wrap the same digest. After the prefix is removed, the remaining value still needs a valid hex, Base64, or Base64URL shape and a decoded byte length that fits the selected algorithm.

A production verifier should define the signed input unambiguously: raw request body, canonical request string, timestamp plus body, or another documented byte sequence. If that byte sequence is vague, a correct HMAC function can still produce mismatches that look like cryptographic failures but are really input-definition failures.

Privacy and Safety Notes:

The signing calculation runs in the browser session. Secret values are omitted from shared URL state, CSV exports, DOCX exports, JSON downloads, and the signature text artifact, but a browser page is still not a secret-management system.

• Use test secrets for examples, support cases, and webhook troubleshooting whenever possible.
• Keep production shared secrets in a vault, deployment secret store, or server-side verifier.
• Rotate a production HMAC secret if it is pasted into an untrusted page, chat, ticket, screenshot, or recording.
• Remember that HMAC authenticates a message under a shared secret; it does not encrypt the message.
• Watch clipboard history, browser extensions, crash reports, and screen sharing when a real secret is visible.

Worked Examples:

Webhook sample match. For the sample message POST /api/orders 2026-05-18T10:00:00Z {"order_id":"A1001","total":135.50} with the secret test-secret-key, HMAC-SHA-256, lowercase hex output, and automatic sha256= prefix, the generated value is sha256=c9db493e614eed02ffa05e3c6d940c111d5807d405525692f095ef51733a1e7a. Pasting that same value into Expected signature changes the summary to Signature match.

Token-style Base64URL output. A canonical string such as GET /v1/invoices date=2026-05-31 can be signed with a Base64URL-encoded test key by setting Key encoding to Base64URL bytes and Output format to Base64URL. The resulting digest omits URL-sensitive + and / characters and drops trailing padding.

Line-ending mismatch. If a provider example fails under Exact text, try Normalize CRLF to LF only when the provider's signing rules support that treatment. A change from Signature mismatch to Signature match is useful evidence for debugging, but production code should not silently normalize signed messages without a documented rule.

Short secret warning. A short secret such as abc with HMAC-SHA-256 still produces a digest, but Verification Checks reports a short test key because 3 parsed key bytes are below the 32-byte SHA-256 digest length. The warning is a setup-quality cue, not a parser failure.

FAQ:

Glossary:

HMAC

A keyed message authentication code built from a cryptographic hash function.

Signed bytes

The exact byte sequence authenticated after text encoding, byte decoding, and any selected newline treatment.

Shared secret

The key known to both signer and verifier. Possession of this value allows valid HMAC values to be produced.

Digest

The raw HMAC output bytes shown as hex, Base64, or Base64URL text.

Header prefix

Text such as sha256=, ripemd160=, or v1= placed before the digest for a provider convention.

Base64URL

A URL-safe Base64 alphabet that uses - and _ instead of + and /, commonly without trailing padding.

References:

• FIPS 198-1, The Keyed-Hash Message Authentication Code (HMAC), National Institute of Standards and Technology.
• RFC 2104, HMAC: Keyed-Hashing for Message Authentication, Internet Engineering Task Force.
• RFC 4648, The Base16, Base32, and Base64 Data Encodings, Internet Engineering Task Force.
• Secrets Management Cheat Sheet, OWASP Cheat Sheet Series.