What an HMAC Generator Actually Produces
An HMAC generator computes a keyed-hash message authentication code — a fixed-size tag that proves a message was produced by someone who holds the same secret key and was not modified in transit. The output is a deterministic string of bytes determined entirely by three inputs: the chosen hash function, the exact bytes of the secret key, and the exact bytes of the message. Any verifier who knows the same secret and feeds in the same byte sequence will calculate the identical tag. Any change to the key, the message or the algorithm produces a completely different tag, which is what makes the construct useful for detecting tampering and authenticating the sender.
The tag is small and portable. With SHA-256 the result is exactly 32 bytes, with SHA-384 it is 48 bytes, and with SHA-512 it is 64 bytes. Those bytes can be rendered in lowercase hexadecimal or in standard padded Base64, and the two renderings describe the very same value. The HMAC Generator page exposes both renderings side by side so a verifier can compare in whichever form the surrounding protocol expects.
What the tag does not do is equally important. HMAC does not encrypt the message. Anyone who sees the plaintext can read it. HMAC does not identify a person — it only proves that the party who generated the tag held the shared secret. And HMAC is not a substitute for a digital signature, because the tag cannot be verified by a third party who does not already know the key: regenerating it requires the same secret on both sides.
How an HMAC Tag Is Built Under the Hood
The construction defined in NIST FIPS 198-1 follows the same shape regardless of which SHA-2 hash you pick. Internally, the algorithm pads or hashes the key to the hash block size, XORs one copy of that padded key with a constant called ipad, hashes that result with the message, XORs another copy of the padded key with a different constant called opad, and finally hashes the two intermediate outputs together. The double-hash structure is what keeps the secret out of the way the underlying hash functions are normally attacked.
You do not need to implement any of this. The HMAC Generator imports your key as a non-exportable WebCrypto HMAC key with the hash you selected, calls subtle.sign, and renders the full returned tag as lowercase hex and padded Base64. The pad constants, inner hash and outer hash all happen inside the browser's cryptography module, so the step-by-step construction is invisible to you but mathematically equivalent to the FIPS 198-1 reference.
The key consequence is that every byte matters. A whitespace difference at the end of a message, a UTF-8 encoding quirk for an accented letter, or a single flipped bit in a hex input produces a totally unrelated tag. That property is the very thing that lets HMAC detect modification, but it is also why you must know the exact bytes the protocol expects before you paste anything into the tool.
Choosing Between SHA-256, SHA-384 and SHA-512
The hash you pick determines the tag length, the underlying block size and the protocol compatibility. You should not pick the one you like best — you should pick the one the receiving system is ready to verify.
| Hash | Tag length | Internal block size | Typical use |
|---|---|---|---|
| HMAC-SHA-256 | 32 bytes | 64 bytes | Most REST APIs, webhook signatures, JWT data segments |
| HMAC-SHA-384 | 48 bytes | 128 bytes | Higher-assurance profiles, compliance regimes that ask for a stronger SHA-2 digest |
| HMAC-SHA-512 | 64 bytes | 128 bytes | Long-lived credentials, internal service-to-service trust, where smaller hashes are not required |
If the protocol documentation says HMAC-SHA256 without further qualification, that is SHA-256. If it says HMAC-SHA512, that is SHA-512. If it says only HMAC and lets you choose, prefer SHA-256 for general web use and move to SHA-512 for internal systems that want a longer tag without changing protocol shape.
UTF-8 vs Hex Mode for the Key and Message
The HMAC Generator lets you set UTF-8 or hex independently for the key field and the message field. That matters because the two modes preserve bytes in different ways. UTF-8 mode is convenient for typing or pasting human text — letters, accented characters, CJK strings and emoji are encoded as their standard UTF-8 byte sequences on the fly. Hex mode is safer for published vectors, raw binary payloads and any time the protocol documents the secret or the data as a literal sequence of bytes.
Hex mode accepts only an even number of hexadecimal digits and preserves every byte including zero. It rejects prefixes like 0x, embedded spaces, colons and odd nibbles, so a stray formatting character cannot silently change a protocol value. UTF-8 mode will happily encode visible spaces and line breaks, which is a feature for normal text but a hazard if the receiving system expects a specific newline convention.
Practical rule: when the spec gives you ASCII bytes or strings, paste them in UTF-8 mode and double-check the encoding. When the spec gives you a hex dump or a known byte sequence, switch to hex mode and type the exact characters without any decoration.
How to Generate a Tag With the HMAC Generator
- Open the HMAC Generator and choose SHA-256, SHA-384 or SHA-512 — pick whichever one the protocol or standard you are following requires. A mismatch here is the single most common reason a calculated tag does not match the expected one.
- For each of the two fields, key and message, choose UTF-8 or hex independently based on the form the protocol documents. If the key is a raw secret string, use UTF-8; if the message arrived as a hex dump from tooling, use hex.
- Enter the bytes exactly. In UTF-8 mode, type or paste without adding invisible trailing whitespace. In hex mode, type only hexadecimal characters with an even count — no 0x prefix, no spaces, no colons.
- Trigger the calculation and read the full tag. The page always shows the complete output for the chosen hash, so a 32-, 48- or 64-byte tag will appear in full rather than truncated.
- Copy the encoding the protocol expects — lowercase hex for most APIs and webhook bodies, standard padded Base64 for systems that ship text-safe envelopes. Convert or trim only when the specification explicitly asks for it.
- Compare the tag to the expected value with a constant-time function on the server side, never with a simple string equality test, to avoid leaking information about how many leading bytes already match.
Reading Hex and Base64 Output Without Mixing Them Up
The same 32-byte HMAC-SHA-256 tag is 64 lowercase hexadecimal characters and 44 Base64 characters. They represent identical bytes, but they are not interchangeable strings. If the verifier expects hex and you send Base64, the comparison will always fail; if the verifier expects Base64url and you send standard Base64, the plus, slash and padding characters may differ and the comparison will fail too.
The HMAC Generator returns standard padded Base64, which uses plus, slash and equal-sign padding. It does not produce Base64url, it does not prepend an algorithm identifier such as sha256=, and it does not wrap the message with its tag. Those transformations are protocol responsibilities. If you need them, apply them only after copying the raw bytes out of the tool, never before. For a compact reminder of which encoding pairs with which hash, the HMAC Generator cheat sheet for hash, encoding and output rules lays out the exact mappings.
Limits, Empty Inputs and Browser-Side Processing
The page caps each decoded field at one million bytes, which is comfortably above typical API and webhook payloads. Empty keys and empty messages are refused by the interface, even though some low-level standards permit zero-length inputs — that refusal simply prevents an accidental click from producing a meaningful-looking tag for the wrong inputs. Long jobs carry an identity token: if you change a value while Web Crypto is still computing, the older result cannot overwrite the newer state.
Everything runs in the current browser tab through the Web Cryptography API, and the inputs do not leave the device. That means the tool is suitable for development secrets, but you should still avoid pasting production credentials into an untrusted machine, because the secret lives in tab memory for as long as it is on screen. Use a generated high-entropy key for protocols that expect one, distribute it through a protected channel, separate keys by purpose, and rotate after any suspected compromise.
Verifying Correctness Against RFC 4231
The RFC 4231 test vectors define a small set of inputs and their expected HMAC tags for SHA-224, SHA-256, SHA-384 and SHA-512, with cases that cover short keys, repeated-byte binary keys, keys shorter than the digest and messages that cross hash block boundaries. The HMAC Generator is locked to eight full conformance tags across those cases, so the easiest way to confirm the tool is behaving the way your protocol requires is to type in a documented RFC 4231 case and compare the tag against the value published in the RFC.
Agreement on those vectors proves that the algorithm, the byte interpretation and the encoding renderings are all correct. It does not prove that your key is secret, that your message is authentic, or that you have picked the right hash for the protocol — those are choices that sit outside the tool and must be made against the governing specification before you ever press generate.