1. Home
  2. Developer tools
  3. HMAC Generator

HMAC Generator

Sign a message with a secret key, or check a signature you received. Handy for webhooks, API request signing and HS256 tokens.

Free, no sign-up. Runs in your browser: nothing is uploaded.

How to use HMAC Generator

  1. Enter the message and the secret key.
  2. Choose the hash algorithm and output format.
  3. Copy the result, or paste a received signature to verify it.

Features

  • SHA-1, SHA-256, SHA-384, SHA-512, SHA3 and MD5 variants
  • Text, hex or Base64 keys and messages
  • Hex, Base64 and Base64URL output
  • Constant-time comparison when verifying
  • Matches RFC 2104 and RFC 4231 test vectors
  • Keys never leave your browser

Supported formats

Input

  • Message and key as text, hex or Base64

You get

  • Hex, Base64 or Base64URL tag

Private by design

Everything you enter is processed by your browser on this device. Nothing is sent to openWorkstand or anyone else, so the HMAC Generator is safe for private and work data. After you have used it once while online, it also works without an internet connection. How local processing works

Good to know

  • Do not paste production secrets into any website; use a test key.
  • The result is only as correct as the exact bytes you hash: whitespace and encoding matter.

Guide

Computing and verifying HMAC signatures

A hash on its own proves nothing about who made a message, since anyone can compute it. An HMAC, a hash-based message authentication code, mixes in a secret key, so only a party who holds the key can produce or check the tag. That is why payment providers, code hosts and cloud APIs sign webhooks and requests with it, and why the HS256 algorithm in JWT is just HMAC-SHA-256. This page computes an HMAC for any message and key and verifies a signature you received.

How HMAC is built

RFC 2104 defines the construction. The key is padded to the hash’s block size and combined with two fixed byte patterns, an inner and an outer pad. The hash runs twice: once over the inner padded key followed by the message, and then over the outer padded key followed by that first result. This double wrapping avoids the length-extension attacks that break a naive hash of key plus message with SHA-256. A key longer than the block size is hashed first, which is why very long keys give no extra strength.

Checked example one: a webhook

The Sample buttons fill the message with {"event":"payment.succeeded","id":"evt_1042","amount":4999} and the key with whsec_test_key_do_not_use. With HMAC-SHA-256 the page shows 86ba756dfc43fd38855ef51267b699da9dcb1dec7af5e9cf3562ace26abd7aec, which is 32 bytes. The Base64 form is hrp1bfxD/TiFXvUSZ7aZ2p3LHex69enPNWKs4mq9euw= and the Base64URL form, which swaps / and + for _ and - and drops padding, is the one you would paste into a JWT. Paste that hex into the verify box and the page confirms a match; change one character of the message and it reports a mismatch.

Checked example two: RFC 4231

To test an implementation of your own, set the message to Hi There, change the key format to hex and enter twenty bytes of 0b. HMAC-SHA-256 is then b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7. Test vectors like this one are the quickest way to find whether a bug sits in the hash, the key handling or the encoding.

Encoding pitfalls

Most failed signature checks come from the bytes, not the algorithm. Hash the raw request body exactly as received: parsing and re-serialising JSON changes spacing and key order. Know whether the key is text, hex or Base64 and choose the matching format here. Remember that a trailing newline counts. Some services sign more than the body, such as a timestamp prefix; build that exact string first.

Algorithms

HMAC-SHA-256 is the modern default. SHA-512 and SHA-384 give larger tags, and SHA-3 and RIPEMD-160 appear in specific systems. HMAC-SHA-1 and HMAC-MD5 are still considered safe as MACs because the construction is robust to collisions, but use SHA-256 for anything new.

Limits

Do not paste a live production secret into any website, including this one, even though the calculation runs locally; use a test key. HMAC proves integrity and authenticity between key holders, and does not hide the message.

Checked against the current version of the HMAC Generator on .

Frequently asked questions

Why is my HMAC different from the one the API sends?

Check three things in order: the exact bytes of the body (raw, not re-serialised JSON), the key (some providers give a Base64 or hex key that must be decoded, others use the text as is) and the hash (SHA-256 is common but not universal).

Can I verify a Stripe-style or GitHub-style signature here?

You can reproduce the core calculation. Stripe signs a timestamp, a dot and the body, and GitHub signs the raw body and sends sha256= followed by hex; build the same string as the provider and paste the header value into the verify box.

Why does my webhook signature not match?

The most common cause is hashing a re-serialised body instead of the exact raw bytes received. Whitespace or key order changes alter the HMAC. Also check the key encoding, since some providers give a Base64 key that must be decoded first.

Is HMAC the same as hashing the key and message together?

No. Simply hashing key plus message is vulnerable to length-extension attacks with SHA-256 and similar hashes. HMAC wraps the hash in two rounds with padded keys to avoid that.

Keep working with the result

openWorkstand also includes a free workspace with documents, spreadsheets, tasks, projects and a calendar that save to a folder on your computer.