What does an HMAC generator example actually show?

An example pairs a documented hash with exact key bytes and message bytes, then displays the resulting tag in the formats the surrounding protocol expects. The HMAC Generator displays both lowercase hex and standard padded Base64 so the value can be quoted in either form.

Why does my computed HMAC differ from the example?

Most mismatches come from a different key, a different message encoding, stray whitespace, a different output encoding (Base64url vs standard Base64), or a tag that the protocol requires to be truncated or prefixed. Run the documented bytes through the HMAC Generator and compare its hex output against the published value to isolate the cause.

Can the same example use UTF-8 text and hex bytes interchangeably?

Only when the UTF-8 bytes of the text are exactly the hex bytes you would otherwise type. Hex mode preserves every byte including zero and rejects prefixes, spaces, colons, and odd nibbles, so it is the safer choice for published vectors and binary fields.

How many bytes does each HMAC variant produce?

SHA-256 produces a 32-byte tag (64 hex characters, 44 Base64 characters), SHA-384 produces a 48-byte tag (96 hex characters, 64 Base64 characters), and SHA-512 produces a 64-byte tag (128 hex characters, 88 Base64 characters). The full output is always shown, and you should only truncate when the protocol explicitly requires it.

Is the message itself protected by an HMAC tag?

HMAC authenticates the message and proves the sender knew the key, but it does not hide the message. Anyone who sees the plaintext can still read it, and anyone who learns the key can forge a valid tag for any message they choose.

HMAC Generator Example: A Real HMAC-SHA256 Walkthrough

An HMAC generator example shows three inputs — a hash choice, a shared secret, and a message — and the resulting keyed-hash tag rendered in both hexadecimal and standard Base64, so two systems that hold the same key can confirm message authenticity by recomputing the same bytes. The tag itself is not encrypted; it is a fixed-length fingerprint that only a party who knows the exact key can produce. HMAC-SHA256 produces 32 bytes, HMAC-SHA384 produces 48 bytes, and HMAC-SHA512 produces 64 bytes, and the chosen hash always drives the tag length. Byte identity is the whole point: the verifier must see the same key bytes, the same message bytes, and the same algorithm, or the recomputed tag will not match. Because hex and Base64 are only renderings of identical bytes, a mismatch in encoding looks like a different value but decodes to the same tag. Knowing what an example shows you, and what it cannot show you, is the difference between a working integration and hours of debugging.

What a real HMAC generator example contains

An HMAC generator example, when shown properly, contains more than just an output string. It pairs a known key with a known message, names the hash, and displays the tag in every format the downstream protocol expects. The HMAC Generator gives you exactly that: a key field, a message field, an independent UTF-8 or hex switch for each, a hash selector, and a tag rendered in both lowercase hex and padded Base64. Each of those three decisions is independent, and any of them can flip the output. A documented example makes those decisions visible. Once you can see which hash was used, which bytes went into the key, and which bytes went into the message, you have everything required to reproduce the tag on your own server, in your own language, or inside the tool itself.

Documentation like RFC 4231 builds its own worked examples around this idea. The RFC publishes exact key bytes, exact message bytes, and the exact tag a correct implementation must produce, so an implementer can test against a known answer. Any time you see a published HMAC value, the surrounding context is doing the same job: it removes ambiguity about what bytes were fed in and which algorithm was selected. The tool on this site is locked to eight full RFC 4231 conformance tags, which means the same idea of byte-exact testing is built into the page.

Choosing SHA-256, SHA-384 or SHA-512 for the example

Before you run an example, the hash choice is fixed by the protocol that will verify your tag. SHA-256 is the most common choice for webhook signatures, JWT HS256 tokens, and most public API signing schemes. SHA-512 is the default where a larger security margin is required, and SHA-384 is occasionally specified for environments that need a middle ground. The hash does not change the meaning of the tag, but it does change the length and the on-wire encoding.

Hash	Tag length (bytes)	Hex characters	Base64 characters	Typical use
HMAC-SHA256	32	64	44	Webhook signatures, JWT HS256
HMAC-SHA384	48	96	64	Some TLS and API contexts
HMAC-SHA512	64	128	88	Higher security margin, AWS-style signing

Pick the hash first, then design the example around it. The HMAC Generator lets you switch between the three without re-entering the key or the message, so you can run the same example under each algorithm and compare tag lengths at a glance. The hex character count is always twice the byte count (one nibble per hex character), and the padded Base64 character count is always a multiple of four because the encoder adds padding characters to round the output up to the next group of three input bytes.

Run a worked HMAC-SHA256 example

For a clean worked example, use the first test vector from RFC 4231, which documents the exact key bytes, message bytes, and expected tag a correct HMAC-SHA256 implementation must produce. The vector is short, fully specified, and widely used as a smoke test for new HMAC implementations.

Open the HMAC Generator in your browser.
Select HMAC-SHA256 as the hash from the algorithm selector.
Set the key mode to hex and enter 0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b. This is 20 bytes of 0x0b and matches the RFC 4231 Test Case 1 key exactly.
Set the message mode to hex and enter 4869205468657265. Those are the UTF-8 bytes for the ASCII string "Hi There". Hex mode is the right choice here because the RFC publishes binary inputs.
Generate the tag. The tool renders the full 32-byte HMAC-SHA256 result in lowercase hex and in standard padded Base64.
Compare the generated hex tag against the RFC's published value: b0344c61d8db38535ca8afceaf0bf12b881dc200c9833da726e9376c2e32cff7. An exact match confirms the tool is computing against the same bytes the RFC uses.
Switch the message mode to UTF-8 and re-enter "Hi There" as text to confirm the tool produces the identical tag for that field. The key (20 bytes of 0x0b) cannot be re-entered as UTF-8 text because 0x0b is not a printable character, so hex mode remains the correct choice for that key.

This same workflow generalizes to any protocol: identify the documented key bytes, identify the documented message bytes, choose the encoding mode that matches the spec, and check the output against any published test value. The HMAC Generator is built around the RFC 4231 vectors precisely so the first run of a new integration can be cross-checked before you trust the tag in production. A second pass under SHA-384 or SHA-512, using the same 20-byte 0x0b key and the same 8-byte "Hi There" message, will show the tag length jump to 96 or 128 hex characters respectively.

Hex versus Base64: two views of the same tag

Once the example is computed, the same 32 bytes appear in two boxes on the screen. The hex box shows every byte as two lowercase characters, giving 64 hex characters for SHA-256 (32 bytes × 2 hex characters per byte = 64). The Base64 box shows the same bytes encoded with the standard RFC 4648 alphabet plus padding, giving 44 characters (the encoder groups the input in blocks of three bytes and emits four characters per group, then pads the final group to a multiple of four). The two strings are visually different but decode to identical bytes.

Format	Length for SHA-256	Character set	Common use	Decodes to the same tag bytes
Lowercase hex	64 characters	0-9, a-f	Webhook headers, debug logs, configuration files	Yes
Standard padded Base64	44 characters	A-Z, a-z, 0-9, +, /, =	JSON request bodies, HTTP headers, binary-safe fields	Yes
Base64url (no padding)	43 characters	A-Z, a-z, 0-9, -, _	JWT signatures, URL path and query components	Yes, with character substitution
Truncated tag	Variable	Depends on protocol	Only when the protocol explicitly requires it	Only if the protocol definition says so

This is the second place examples go wrong. Hex and Base64 are not interchangeable in transit, because the receiving system may only parse one of them, but they represent the same tag. A protocol that publishes a Base64 example will not accept a hex string in the same field, even though the underlying bytes are identical. The HMAC Generator always emits the full tag in both encodings, so the example can be quoted in either form as long as the receiver expects that form. For a closer look at how those two renderings compare across all three hash variants, the HMAC-SHA256 Tag Generator: Hex and Base64 Guide walks through the same comparison with additional inputs.

Why a recomputed tag does not match the example

Even when the algorithm is the same, four common differences can flip the output. The first is key bytes: a key of "secret" in UTF-8 is six bytes (73 65 63 72 65 74), and for ASCII-only characters the UTF-8 encoding equals those byte values by definition rather than coincidentally. The second is message encoding: the string "Hi There" in UTF-8 is 48 69 20 54 68 65 72 65, while the same string in UTF-16LE is a different 16-byte sequence. The third is whitespace: a trailing newline, a leading space, or a Windows-style CRLF instead of LF changes the message bytes and therefore the tag. The fourth is the encoding of the output itself: the tool always emits lowercase hex and standard padded Base64, but the verifier may expect Base64url, may prepend an algorithm identifier like "SHA256=", or may require the tag to be truncated to a fixed length.

The fastest way to debug a mismatch is to reproduce the example in the HMAC Generator under the exact conditions of the failing integration. Force the key mode and message mode to match the spec, paste the bytes, and confirm the generator's hex output matches what the receiver computed. If it does, the problem is on the receiving side. If it does not, the problem is in how the key or message is being fed in. A full RFC 4231 vector, like the SHA-256 case above, is the most reliable starting point, because every byte and the expected output are documented and unambiguous.

Key handling, byte limits, and protocol rules

The example only protects you if the surrounding practices are correct. A few rules apply regardless of which example you copy. Use independently generated high-entropy key material appropriate for the protocol, distribute it through a protected channel, separate keys by purpose, and rotate after any suspected compromise. A human password is rarely a strong HMAC key; if a password must become a key, run it through the protocol's required password-based KDF with the exact parameters the application specifies, rather than improvising.

The page limits each decoded field to 1,000,000 bytes, which is large enough for typical payloads but not a substitute for streaming. The interface rejects empty keys and empty messages, even though some low-level standards technically allow zero-length input, because an accidental click should never produce a publishable tag. Asynchronous jobs carry an identity token, so changing input while Web Crypto is working prevents an older result from overwriting the new state. The tool does not emit Base64url, does not prepend an algorithm identifier, and does not package the message with its tag. Each of those transformations is the protocol's job, and the right place to apply them is wherever the spec says to apply them. Hex and Base64 are only renderings of identical tag bytes, and decoding either one back to raw bytes gives the same 32, 48, or 64-byte sequence the hash produced.