SSOGEN / Free tools / HMAC Generator and Verifier: Sign or Check a Message in Your Browser

Free tool

HMAC Generator and Verifier: Sign or Check a Message in Your Browser

An HMAC generator computes a keyed hash that proves a message is unchanged and came from someone who holds the key. Enter a key and a message to get the HMAC, or paste a signature to check it. Everything runs in your browser.

Plan a trial

Generate or verify an HMAC here

Choose Generate to compute an HMAC, Verify to compare it with a signature you received, or Webhook signature to check a raw request body against a header such as X-Hub-Signature-256: sha256=....

What to do Generate Verify Webhook signature

Algorithm

Key is entered as

Secret key required

Text keys are converted to bytes with UTF-8, the same as most server code does. A hex or base64 key is decoded to its bytes first. Use test keys only.

Random key of

Message is entered as

Message required

Private by design. The key and message are processed in this page with the browser's own crypto, and nothing is uploaded. Even so, paste test keys here and never a live production secret. A random key is made with crypto.getRandomValues and never leaves the page.

Free, in your browser: the key and the message are never sent anywhere. Use test keys, not live secrets.

What an HMAC is

An HMAC (hash-based message authentication code) is a short value computed from a message and a secret key. Anyone who holds the same key can recompute it and compare. A match shows that the message is unchanged and that the sender knew the key.

The construction is defined in RFC 2104 as H(K XOR opad, H(K XOR ipad, text)), where H is a hash such as SHA-256.

HMAC is not encryption. The message stays readable, and the code only proves integrity and origin.

Which algorithm to choose

Algorithm	Output	Block size	When to use it
HMAC-SHA-256	32 bytes (64 hex characters)	64 bytes	The default for new work and for most webhook signatures
HMAC-SHA-384	48 bytes	128 bytes	When a specification asks for it
HMAC-SHA-512	64 bytes	128 bytes	When a specification asks for it, or on 64-bit servers
HMAC-SHA-1	20 bytes	64 bytes	Legacy only, to match an existing system

RFC 2104 allows SHA-1 and uses it as an example hash. HMAC-SHA-1 remains for compatibility with older systems. New designs should start with SHA-256, so this tool labels SHA-1 as legacy and does not recommend it.

How keys and messages are read

The bytes you sign decide the result, so the tool states how it reads each field.

Text is converted to bytes with UTF-8. This matches most server code. A key written as text and the same key written as hex are different bytes and give different signatures.
Hex reads each pair of digits as one byte. Spaces, colons and a leading 0x are ignored.
Base64 accepts the standard and the URL-safe alphabet, with or without padding.
A key longer than the block size is hashed first, as RFC 2104 specifies. A key shorter than the hash output is flagged, because RFC 2104 strongly discourages it.

The output is shown as hex, base64 and base64url, with its length in bytes.

Verify a signature and find out why it fails

Verify accepts a signature as hex, base64 or base64url, with or without a sha256= prefix. A prefix of sha1=, sha256=, sha384= or sha512= also selects the algorithm. The comparison uses crypto.subtle.verify, which the browser runs in constant time.

When the result is a mismatch, the tool recomputes the HMAC for the usual mistakes and lists only the ones that match:

a trailing newline added or removed, or CRLF instead of LF line endings;
JSON parsed and written out again, in compact or two-space form, instead of the raw bytes;
a key that should be read as hex or base64 but was entered as text;
an algorithm that does not fit the signature length (20, 32, 48 or 64 bytes).

If none matches, the tool lists the remaining causes, such as signing the hex text of a digest instead of its bytes.

Worked example

Use Fill in an Acme example to load this input, or enter it by hand.

Field	Value
Algorithm	HMAC-SHA-256
Key (text)	`acme-test-signing-secret-do-not-use-in-production`
Message (text)	`{"event":"invoice.paid","id":"evt_1042","account":"acme.example","amount":4200}`

The result:

hex       86a25eda452a30c5e4eebebf2978b0ae32806010ec56a85decfbae4597e19e25
base64    hqJe2kUqMMXk7r6/KXiwrjKAYBDsVqhd7PuuRZfhniU=
base64url hqJe2kUqMMXk7r6_KXiwrjKAYBDsVqhd7PuuRZfhniU

Add one newline at the end of the message and the hex becomes 061711a410285ed68a898dcc0c7862e9748d1d8e98d6ff6ee23972bd54a540a9. Verify the first signature against the message with that newline and the tool reports a mismatch, then names the trailing newline as the cause.

Check a webhook signature

Many services sign each webhook with an HMAC of the raw request body and send it in a header, often as sha256=<hex>. To check one:

Copy the body exactly as received, before any JSON parser touches it.
Copy the signing secret from the sender. Treat it as text unless the sender says it is hex or base64.
Paste the header line into Webhook signature.

The tool reads the prefix, picks the algorithm and reports a match or mismatch. A receiving server should do the same on every request and reject a failed one.

Test vectors

The logic in this page is tested against the published vectors, which you can also enter by hand to check any other implementation.

Source	Key (hex)	Message	HMAC-SHA-256
RFC 4231 test case 1	`0b` repeated 20 times	`Hi There`	`b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7`
RFC 4231 test case 2	`4a656665` (`Jefe`)	`what do ya want for nothing?`	`5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843`

RFC 4231 test cases 1 to 4 define HMAC-SHA-256, SHA-384 and SHA-512 results, and RFC 2202 test cases 1 to 4 define HMAC-SHA-1. For test case 1 with SHA-1 the result is b617318655057264e28bc0b6fb378c8ef146be00.

Check an SSOGEN webhook delivery

SSOGEN signs each webhook delivery with HMAC-SHA-256 over the text <t>.<body>, using the signing secret as a text key. It sends t=<unix seconds>,v1=<hex> in the X-SSOGEN-Signature header.

To test one here:

Choose Verify.
Enter the secret as text.
Enter the message as the value of t, a dot and the exact body.
Paste the header. The tool takes the v1 value.

The full procedure, including the five-minute time check, is in webhook signature verification and receivers.

What is an HMAC?

An HMAC is a keyed hash. It combines a secret key with a message and a hash function such as SHA-256 to produce a fixed-length code. A receiver with the same key recomputes the code and compares it. A match shows the message is unchanged and came from a key holder.

How do I verify an HMAC signature?

Recompute the HMAC over the exact bytes that were signed, using the same key and algorithm, and compare it with the received value in constant time. Decode the signature to bytes first, because hex and base64 are only ways to write them. Do not compare with a plain string equality check.

Is HMAC-SHA1 still secure?

RFC 2104 allows HMAC-SHA-1, and many older integrations still use it. It is a legacy choice and this tool does not recommend it. Use HMAC-SHA-256 or stronger for new systems, and keep SHA-1 only where an existing integration requires it and cannot be changed.

What is the difference between a hash and an HMAC?

A plain hash such as SHA-256 has no key, so anyone can compute it and an attacker can replace both a message and its hash. An HMAC needs a secret key, so only a key holder can produce a valid code. A hash checks accidental change; an HMAC also checks origin.

How long should an HMAC key be?

Use at least as many random bytes as the hash output: 32 bytes for SHA-256, 48 for SHA-384 and 64 for SHA-512. RFC 2104 strongly discourages keys shorter than the output. A longer key adds little strength. Generate it with a secure random source, as this tool does, and rotate it.

Why does my HMAC not match the expected value?

The usual cause is that the signed bytes differ: a trailing newline, other line endings, or JSON written out again. Next come a key read as text instead of hex or base64, and a wrong algorithm. The Verify mode on this page tests these variants and names the one that matches.

Where to go next

Sign. Sign a token with the JWT generator.
Read. Read one with the JWT decoder.
Secret. Make a strong random secret with the API key generator.
More. The rest of the set is on the free SSO tools page.

Sources, all read 2026-10-27: RFC 2104, HMAC: Keyed-Hashing for Message Authentication; RFC 4231, test vectors for HMAC-SHA-224, SHA-256, SHA-384 and SHA-512; RFC 2202, test cases for HMAC-MD5 and HMAC-SHA-1.