{{ summary.heading }}
{{ summary.primary }}
{{ summary.line }}
{{ badge.label }}
MSG KEY {{ hmacPipelineAlgorithmLabel }} DIGEST
Paste the webhook body, canonical request string, or test payload. Browse/drop a TXT, JSON, CSV, or log file to load local text.
{{ messageSourceHint }}
This changes the message bytes signed by HMAC; it is not display-only.
Enter the shared secret as UTF-8 text, hex bytes, Base64, or Base64URL according to the key encoding below.
{{ secretActionHint }}
This changes the secret bytes used by HMAC; it is not display-only.
Choose the HMAC hash used by the provider, header, or API signing spec.
The same raw digest can be copied as lowercase hex, uppercase hex, Base64, or Base64URL.
Auto uses the selected algorithm prefix such as sha256=, sha224=, sha1=, ripemd160=, or md5=.
Keep it short and include any equals sign, colon, or space you need in the copied header value.
Optional. Paste a webhook header value or digest to verify line endings, key encoding, and output format.
Use Auto for ordinary provider headers; explicit formats help when comparing across encodings.
Applies only to UTF-8 text messages. Keep Exact unless the provider documentation says it trims a final newline or normalizes CRLF line endings.
This affects only the local input display; secret values are never written into the shared URL state.
{{ params.show_secret ? 'Visible' : 'Hidden' }} 
{{ signatureArtifact }}
{{ header }} Copy
{{ cell.value }} {{ cell.value }}
Tags: Cryptography, Devtools, Security
Export to PDF Fullscreen
Customize
Advanced
:

Hash-based message authentication code, or HMAC, is a keyed digest used to check that a message matches a shared secret and has not changed in transit. It is common in webhook verification, API request signing, canonical request tests, and support cases where two systems need to prove they signed the same bytes with the same key.

An HMAC is not ordinary hashing. A plain hash only fingerprints data, while HMAC mixes the message with a secret key before producing the final digest. Anyone can recompute a plain hash from the message alone. Recomputing an HMAC requires the shared secret, so a matching value gives stronger evidence that the sender and verifier used the same secret and the same message bytes.

HMAC signing flow A message and shared secret feed an HMAC function, producing a digest that can be formatted and compared with an expected signature. Message exact bytes Shared secret HMAC selected SHA family Digest hex or Base64 Compare Header optional prefix Same message bytes + same secret + same algorithm = same HMAC bytes.

Most HMAC mistakes come from byte-level differences, not from the math itself. A trailing newline, a different line-ending style, a secret pasted as text instead of decoded bytes, or a provider header copied with the wrong prefix can turn a correct integration into a mismatch. The digest format matters too: lowercase hex, uppercase hex, Base64, and Base64URL can display the same raw HMAC bytes in different text forms.

Use browser-based HMAC generation for test vectors, webhook debugging, documentation examples, and reproducing provider signatures. Production shared secrets should stay in vaults, deployment systems, or server-side verification code, because a copied digest is harmless only when the key and message are handled safely.

How to Use This Tool:

The workflow signs the visible message with the selected secret and updates the comparison rows as inputs change.

  1. Enter the exact value in Message to sign, or load a local TXT, JSON, CSV, or log file. The local text file limit is 512 KB, and whitespace is part of the signed message.
  2. Set Message encoding. Use UTF-8 text for ordinary webhook bodies and canonical strings. Use Hex bytes, Base64 bytes, or Base64URL bytes only when the message is supplied as encoded bytes.
  3. Enter Secret key and choose Key encoding. Use Generate test key for a local 32-byte Base64URL test secret, not for issuing a production secret.
  4. Choose Algorithm to match the verifier. HMAC-SHA-256 is the practical default for new signatures, while HMAC-SHA-1 and HMAC-MD5 are compatibility choices for legacy systems.
  5. Choose Output format and Header prefix. Prefixes such as sha256= or v1= change the copied header value, not the raw HMAC bytes.
  6. Paste an optional Expected signature and leave Expected format on Auto detect unless the pasted value is ambiguous. The result summary changes to match, mismatch, or parse-error status.
  7. Open Advanced only when provider documentation says the message is normalized. 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.

If generation is blocked, fix the warning before trusting the digest. Common causes are an empty required secret, malformed hex, invalid Base64 or Base64URL text, an oversized text file, or a browser where random test-key generation is unavailable.

Interpreting Results:

The current signature appears in the summary and in HMAC Signature. The prefixed header value is useful when a provider expects a full header-style value. The raw digest is useful when documentation expects only the digest text.

What you see Meaning Next check
Signature match The generated HMAC bytes match the pasted expected value after parsing. Confirm the message, key, algorithm, and normalization rule are the intended ones.
Signature mismatch The verifier value and generated HMAC bytes differ. Check hidden line endings, trailing newline, key encoding, and selected algorithm first.
Expected parse error The expected value could not be read as the selected or detected format. Remove unrelated header text or choose Hex, Base64, or Base64URL explicitly.
short test key The secret is shorter than the selected digest byte length. Use a longer random shared secret for new integrations, then store it in a managed secret system.
Digest changes after output format changes The displayed text changed form; the underlying HMAC bytes can still be the same. Compare using Verification Checks instead of judging only by string shape.

Signature Ledger gives the generated header, raw digest, algorithm, key encoding, message size, prefix, and security posture in one table. Verification Checks focuses on the expected-value parser, key-byte cue, message treatment, prefix fit, and secret handling. Algorithm Outputs recomputes the same parsed message and key across every supported algorithm so you can spot a wrong-family mismatch quickly.

A matching HMAC is a narrow result. It says the same signing inputs reproduced the same authentication code. It does not prove the provider account is legitimate, that the message is safe to process, or that the shared secret has not leaked elsewhere.

Technical Details:

HMAC wraps a cryptographic hash function in an inner and outer keyed construction. The message is first hashed with a key-derived inner pad, then that inner digest is hashed again with a key-derived outer pad. This construction is why HMAC is a message authentication code rather than just a salted hash.

The selected hash family controls digest size and compatibility, while the secret key controls who can reproduce the value. SHA-256, SHA-384, and SHA-512 are current SHA-2 choices. SHA-1 and MD5 remain present here only for reproducing old integrations that still name them. For a new signing scheme, match the peer specification when one exists; otherwise prefer a SHA-2 HMAC with a random, protected secret.

Formula Core

The HMAC construction can be summarized as two hash passes over a block-sized key form and the message bytes.

HMAC ( K , m ) = H ( ( K0 ⊕ opad ) ∥ H ( ( K0 ⊕ ipad ) ∥ m ) )

Here K is the shared secret, m is the exact message byte sequence, H is the selected hash function, and K0 is the key adjusted to the hash block size. The inner pad and outer pad are fixed byte patterns used by the standard HMAC construction. Output formatting happens after the raw HMAC bytes are produced.

Transformation Core

Stage What changes it Why it matters
Message bytes Message to sign, Message encoding, and UTF-8 message treatment. HMAC signs bytes, so text that looks similar can sign differently.
Key bytes Secret key and Key encoding. A secret typed as UTF-8 text is not the same as the same-looking value decoded from hex or Base64.
Hash family Algorithm. The algorithm changes digest length, provider compatibility, and security posture.
Displayed signature Output format. Hex, Base64, and Base64URL are encodings of digest bytes, not separate signing operations.
Copied header value Header prefix and optional custom prefix. The prefix helps match provider header conventions without changing the digest.
Expected comparison Expected signature and Expected format. The expected value is parsed to bytes before comparison, so display format differences can still match.
Algorithm option Digest bytes Lowercase hex characters Practical reading
HMAC-SHA-256 32 64 Recommended default for new webhook and API signing workflows when no peer rule says otherwise.
HMAC-SHA-384 48 96 Strong SHA-2 option used when a verifier or policy names SHA-384.
HMAC-SHA-512 64 128 Strong SHA-2 option with the longest digest in the current set.
HMAC-SHA-1 20 40 Legacy compatibility only. Use it when an existing provider requires it.
HMAC-MD5 16 32 Legacy compatibility only. Do not choose it for new security-sensitive signing.

Digest text length follows from the output encoding. Lowercase and uppercase hex use two characters per byte. Base64 is usually shorter and may include padding characters. Base64URL swaps the URL-sensitive Base64 characters and omits trailing padding here, which fits token-like header values and documentation examples that avoid +, /, and =.

The comparison path strips common provider-style prefixes before parsing the expected value. That makes a pasted value such as sha256=... comparable to a raw generated digest, but it does not guess the correct message normalization or key encoding. Those inputs must still match the signing system exactly.

Privacy and Safety Notes:

The signing work happens in the browser session. The secret value is kept out of exported tables, downloaded JSON, and shared links, but that does not make a browser page a safe secret-management system. Clipboard history, screen sharing, browser extensions, crash reports, downloaded artifacts, and pasted support tickets can still expose sensitive material.

  • Use test secrets when reproducing webhook examples or support cases.
  • Keep production shared secrets in a vault or server-side verifier, not in a browser tab.
  • Rotate a production HMAC secret if it is pasted into an untrusted page, chat, ticket, or screenshot.
  • Use constant-time comparison in production verification code so a mismatch does not leak position-by-position timing clues.
  • Remember that HMAC authenticates a message under a shared secret; it does not encrypt the message.

Worked Examples:

For a typical webhook test, paste the exact request body into Message to sign, leave Message encoding as UTF-8 text, enter the provider's test secret, choose HMAC-SHA-256, and keep Output format as lowercase hex. If the provider header starts with sha256=, keep Header prefix on automatic prefixing and paste the provider value into Expected signature. A match means the body, secret, algorithm, and digest bytes line up.

For a Base64URL signing example, enter a canonical string, choose a Base64URL-encoded key with Key encoding set to Base64URL bytes, and set Output format to Base64URL. The copied digest will use URL-safe characters without padding. If the receiving system expects a raw digest, use No prefix; if it expects a header style, add the required prefix separately.

For a line-ending mismatch, paste the same message twice: first with Exact text, then with Normalize CRLF to LF. If only the normalized run matches the provider, record that behavior with the integration notes. Do not silently normalize messages in production unless the provider's signing specification says to do so.

FAQ:

Should I choose SHA-256, SHA-384, or SHA-512?

Match the system that will verify the signature. If you are defining a new simple webhook-style signature and have no outside requirement, HMAC-SHA-256 is the broad default.

Why does the digest change when I switch message encoding?

The encoding setting changes the bytes being signed. UTF-8 signs the characters as text, while hex, Base64, and Base64URL decode the field into bytes first.

Does uppercase hex make a different HMAC?

No. Uppercase and lowercase hex are different text displays of the same digest bytes. A strict system may still require one style for string comparison.

Can I use this with a production webhook secret?

Use test secrets here whenever possible. A production secret belongs in the server-side verifier or a managed secret store. If a live secret is exposed during troubleshooting, rotate it.

Why does the expected signature fail to parse?

The pasted value may contain unrelated header text, invalid hex, invalid Base64 characters, or a format that auto detection cannot infer. Strip extra text or choose the expected format directly.

Glossary:

HMAC
A keyed message authentication code built from a cryptographic hash function.
Message bytes
The exact byte sequence being signed after text or byte decoding and any selected normalization.
Shared secret
The key known to the sender and verifier. Possession of this value allows valid HMACs to be produced.
Digest
The raw HMAC output bytes shown as hex, Base64, or Base64URL text.
Header prefix
Text such as sha256= or v1= placed before the digest to match a provider header convention.
Base64URL
A URL-safe Base64 alphabet that uses - and _ instead of + and /.

References: