An HMAC generator cheat sheet is the quick reference that maps every HMAC decision to one concrete action: which hash to pick, how to enter the exact key and message bytes, and which output encoding the receiving system actually expects. A keyed-hash message authentication code (HMAC) combines a cryptographic hash with a shared secret key, and a verifier that holds the same secret and feeds in the same message bytes can recompute the identical tag. The tag authenticates the sender and detects modification, but it does not conceal the message. Anyone who sees the plaintext can still read it, and anyone who learns the secret can forge valid tags. That is why every cheat-sheet line item — hash choice, byte encoding, output format — exists: changing any one of them produces a different tag, and the verifier rejects it as invalid.
This page is built around the HMAC Generator, which runs entirely in the browser through the Web Cryptography API and never uploads key material to a server. Everything below assumes you have already identified the exact algorithm, key bytes, and message bytes from the governing protocol specification.
Hash Selection Quick Reference
The HMAC algorithm is HMAC; the choice that changes tag length and acceptance is the underlying hash. Pick the hash the protocol names, not the strongest one available.
| Hash | Tag length (bytes) | Hex characters | Standard Base64 characters | Typical use |
|---|---|---|---|---|
| SHA-256 | 32 | 64 | 44 | JWT HS256, AWS Signature v4, most REST webhooks |
| SHA-384 | 48 | 96 | 64 | Protocols that explicitly request SHA-384 |
| SHA-512 | 64 | 128 | 88 | High-assurance APIs and long-message signing |
The relationship is fixed: hex characters equal tag_bytes × 2, and standard padded Base64 equals ceil(tag_bytes / 3) × 4. SHA-256 always returns 32 bytes, SHA-384 always returns 48, and SHA-512 always returns 64. A tag that is the wrong length cannot be made to match by re-encoding; pick the hash first, then generate.
Encoding the Key and Message Bytes
HMAC works on bytes, not on text. Every cheat sheet starts here because the single most common cause of a mismatched tag is that "the text looks the same" but the bytes are different. The HMAC Generator exposes two encodings for each field — UTF-8 and hex — and they are chosen independently for the key and the message.
UTF-8 mode treats the field as text and encodes it with the standard UTF-8 rules. That means accented letters, CJK characters, and emoji each occupy multiple bytes, and a single character can shift the byte count by more than one. Hex mode accepts only an even number of hexadecimal digits, preserves every byte (including zero), and rejects the 0x prefix, spaces, colons, and odd nibbles so that an accidental formatting character cannot silently change a protocol value.
Prefer hex mode when the protocol or published test vector supplies raw bytes, a binary header, or a non-printable key. Prefer UTF-8 mode when the specification names the secret as "the API key string" or the message as "the request body as text". When the protocol is silent about encoding, the source of truth is the implementation that signs or verifies — copy the bytes that implementation consumes, not the bytes that look right in an editor.
How to Generate an HMAC Tag Step by Step
- Open the HMAC Generator and confirm the protocol expects a complete HMAC tag — not a raw hash, not a signature envelope, not an algorithm-prefixed identifier.
- Select the hash the protocol specifies: SHA-256, SHA-384, or SHA-512. The default of SHA-256 is wrong if the verifier expects anything else.
- Choose UTF-8 or hex independently for the key field, then enter the exact bytes. For a UTF-8 secret, paste the secret string with no surrounding whitespace; for a hex key, paste an even number of hexadecimal digits with no 0x prefix or separator.
- Choose UTF-8 or hex independently for the message field and enter the exact bytes the verifier will hash. Mind trailing newlines: a final \n on the sender side and no \n on the verifier side produces different tags.
- Generate the tag and copy either the lowercase hex or the standard padded Base64. Both renderings are the same tag bytes; only the format changes.
- Convert or truncate the tag only when the protocol explicitly requires it. Common transforms include truncation to N bytes, prepending an algorithm identifier, packaging the message with its tag, or switching to Base64url. Apply each rule only from the specification; do not edit a valid tag by eye.
Output Format Rules: Hex vs Base64
The HMAC Generator always returns the full tag in two renderings. Choosing between them is a protocol question, not a preference.
| Encoding | Shape | Where it is required |
|---|---|---|
| Lowercase hex | 64 / 96 / 128 hex digits, no prefix | JWT signature segments, many webhook headers, debug logs |
| Standard padded Base64 | 44 / 64 / 88 characters with trailing = padding | OAuth 1.0 signatures, some REST APIs |
| Base64url (not emitted) | Same length, replaces + with - and / with _, drops padding | JWT and some modern APIs — paste the standard Base64 and convert externally |
Hex and Base64 encode identical bytes. The page does not emit Base64url, does not prepend an algorithm identifier, and does not package the message with its tag. If the protocol expects any of those, the format transform is a separate step that happens after the HMAC is generated. Visually similar encodings are not interchangeable: decoding a Base64url value as standard Base64, or vice versa, produces different bytes and a verification failure.
Why Your Tag Differs From Another Tool
When two implementations produce different HMAC tags for what looks like the same input, walk this checklist in order. Each item is a documented mismatch cause, and the practical conventions for the encoding leg match those in the Base64 decode cheat sheet.
- Wrong hash. SHA-256, SHA-384, and SHA-512 each return different tags. Confirm the verifier uses the same algorithm name.
- Wrong byte encoding. The same key or message text in UTF-8 and in hex yields different bytes. Confirm both sides agree on UTF-8 vs raw hex.
- Hidden whitespace or newline. A trailing space, carriage return, or line feed is part of the message bytes. Strip both sides to the same convention.
- Truncated tag. Some protocols keep only the leftmost N bytes; the HMAC Generator always returns the full tag. Truncate only if the protocol says so.
- Base64 variant mismatch. Standard padded Base64 and Base64url are not interchangeable. Decode the expected value with the matching alphabet.
- Algorithm prefix. A few protocols prepend an identifier such as HMAC-SHA256= to the tag. The generator does not add this prefix.
If the checklist does not resolve the mismatch, generate the same input against a published test vector on both sides. Agreement on a known vector proves the implementation works; the remaining mismatch is then the application protocol, not the HMAC primitive.
Verify Against RFC 4231 Test Vectors
The HMAC Generator is locked to eight RFC 4231 conformance tags covering short keys, binary repeated-byte keys and data, keys smaller than the digest, and data that crosses hash block boundaries. SHA-256 and SHA-512 are each checked for four independent inputs, and the UI also exposes SHA-384 because the Web Cryptography API defines it. Working from a known vector, rather than from a fresh signing run, is the fastest way to confirm that byte encoding, hash choice, and tag rendering all match the verifier before any production secret is involved.
Use hex mode for the published vectors: the inputs are listed as raw bytes, and pasting them through UTF-8 mode would silently multi-byte encode characters that look ordinary but are not. Compare the complete tag in the encoding the verifier expects. Per the RFC 4231 test vectors, agreement on a known vector proves shared key and byte consistency — it does not prove message confidentiality, and it does not protect a production secret that has been pasted into an untrusted device.
For a deeper look, see Punycode Converter Cheat Sheet: RFC 3492 Rules and Limits.