HMAC-SHA-256 produces a complete 32-byte authentication tag from a shared secret and message, and an HMAC generator lets you calculate that tag without encrypting or hiding the message. For a beginner, the essential task is to match four things: the hash algorithm, the exact key bytes, the exact message bytes, and the output format required by the receiving system. The HMAC Generator supports HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512. You can represent the key and message independently as UTF-8 text or exact hexadecimal bytes, then receive the complete tag in lowercase hexadecimal and standard padded Base64. Those two outputs encode the same tag; they are not two different HMAC results. The page uses the browser's Web Cryptography API, imports the selected key bytes as a non-exportable HMAC key, and does not send inputs to the site server. Key material stays in the current tab. That makes the tool useful for checking a documented vector, preparing a protocol request, or reproducing a value that another system should calculate. Begin only after you identify the governing protocol's algorithm, byte encoding, field order, whitespace convention, and tag rules. Try the HMAC Generator to do this in your browser.
HMAC Basics for First-Time Users
An HMAC combines a cryptographic hash with a shared secret key. The sender computes a tag over the exact message bytes, and a verifier with the same secret and message bytes can calculate the same tag. A mismatch can expose message modification, while matching tags support authentication of a party that knew the shared key. Anyone who learns that key can also create valid-looking tags, so HMAC depends on strong key protection.
HMAC does not conceal the message. A recipient can still read plaintext, and an observer who sees it can read it too. Encryption is a separate operation. The HMAC construction itself is defined in NIST FIPS 198-1.
Choose the Hash and Field Encodings
Use the hash named by the governing protocol rather than choosing based on personal preference. The selected hash determines the full tag length:
| Algorithm | Full tag size | Selection rule |
|---|---|---|
| SHA-256 | 32 bytes, or 256 bits | Use when the protocol specifies HMAC-SHA-256. |
| SHA-384 | 48 bytes, or 384 bits | Use when the protocol specifies HMAC-SHA-384. |
| SHA-512 | 64 bytes, or 512 bits | Use when the protocol specifies HMAC-SHA-512. |
The page always displays the full tag. Confirm that the protocol expects that full result. If its specification defines truncation, an algorithm prefix, or a different transport encoding, record the exact rule but leave the original full tag unchanged until that step.
Input encoding is a separate decision from algorithm selection. The key and message can each use UTF-8 or hexadecimal independently.
| Input mode | Bytes supplied to HMAC | Beginner check | Best fit |
|---|---|---|---|
| UTF-8 | The UTF-8 encoding of the text entered in that field. | Spaces, line endings and multi-byte characters affect the result. | |
| Hexadecimal | The exact byte represented by each pair of hexadecimal digits. | Use complete byte pairs without prefixes or separators. |
These modes control how input bytes are supplied; they do not select the HMAC algorithm. Hexadecimal is especially useful for published test vectors and binary fields because every byte is explicit.
Generate a Full HMAC Tag
- Confirm the algorithm. Choose SHA-256, SHA-384 or SHA-512 as specified by the governing protocol, and confirm that a full HMAC tag is expected before applying any separately defined transformation.
- Enter the secret key. Select UTF-8 or hexadecimal for the key field. Enter the exact secret text or complete byte sequence required by the protocol, without adding labels, prefixes or formatting.
- Enter the message separately. Choose its own UTF-8 or hexadecimal mode. Preserve the specified field order, capitalization, spaces, punctuation and any required trailing newline.
- Generate the tag. Run the generator. The browser imports the chosen key bytes as a non-exportable Web Crypto HMAC key, and the signing operation returns the complete tag. The page renders those same bytes as lowercase hexadecimal and standard padded Base64.
- Copy the required representation. Use lowercase hex when the receiving system expects hexadecimal. Use standard padded Base64 when that is the documented format. Do not treat visually similar encodings as interchangeable.
- Finish according to the specification. Convert or truncate the tag only when the protocol explicitly requires it. Store or transmit the message and tag in the prescribed fields rather than assuming the generator has packaged them for you.
Input boundaries: Each decoded key or message field is limited to 1,000,000 bytes. The interface rejects empty keys and empty messages to prevent accidental results, even though some low-level standards can define behavior for zero-length data. Asynchronous jobs carry an identity token, so a result from older input cannot overwrite a newer input state.
Control Every Input Byte
HMAC operates on bytes, not on the visible meaning of text. For each field set to UTF-8, the tool encodes the entered text as UTF-8. Accented letters, CJK characters and emoji can occupy multiple bytes, while a space or trailing newline adds bytes of its own. Do not trim or replace line endings unless the protocol tells you to do so. Before generating the tag, confirm whether each field should use UTF-8 encoding or hexadecimal bytes.
Hexadecimal mode preserves every byte, including zero-valued bytes. It accepts only an even number of hexadecimal digits and rejects prefixes, spaces, colons and odd nibbles. This strict parsing prevents an accidental formatting character from silently changing a protocol value. A compact hex string and a text string that appear related are not necessarily the same input, so use the mode specified for each field.
Published vectors and binary payloads are often clearest in hexadecimal because the byte boundaries remain visible. For ordinary text, UTF-8 is more readable, but the encoded byte sequence still governs the result.
Deliver the Tag in the Required Form
Lowercase hexadecimal and standard padded Base64 are two renderings of identical tag bytes. Decoding either representation produces the same full HMAC value. The output choice matters because the receiving protocol defines how the tag is represented and transported.
The generator does not emit Base64url, prepend an algorithm identifier, or place the message and tag inside a package. A protocol may require one of those formats, but it may instead require a canonical request string or binary envelope. If a canonical request string is the data being authenticated, assemble its exact bytes before generation. If the final format packages the message with an already generated tag, build that package separately according to the specification. Never shorten a full tag by eye or remove characters until it appears to fit.
Trace a Result Mismatch
When two systems produce different tags, compare the same decisions in the same order:
- Check that both systems use SHA-256, SHA-384 or SHA-512 as specified.
- Compare the exact key bytes, including any required password derivation.
- Confirm that the key and message use their intended UTF-8 or hexadecimal interpretations.
- Check whitespace, line endings, trailing newlines, character encoding and field order.
- Verify whether the signed payload is a raw message, canonical request string or defined envelope.
- Compare the complete tag in the required representation, including any explicit truncation or Base64url rule.
For controlled checks, use the published RFC 4231 test vectors rather than an improvised example. This generator's correctness checks are locked to eight full conformance tags: four for SHA-256 and four for SHA-512. The cases cover short keys, repeated binary keys and data, keys smaller than the digest, and data crossing hash block boundaries. Reproducing a vector byte-for-byte is more useful than switching algorithms until one result happens to look plausible.
Handle Keys as Security Material
A correct HMAC calculation does not make a weak key safe. Use independently generated, high-entropy key material appropriate for the protocol, distribute it through a protected channel, separate keys by purpose, and rotate them after a compromise. A human password is usually too low entropy to serve as a raw HMAC key. When an application permits password-based keys, use the exact password-based key derivation function and parameters required by that application rather than improvising.
If the protocol expects generated random secret text, use independently generated, high-entropy key material appropriate for the protocol. Confirm that printable text is the required key format; some systems expect raw key bytes instead. Do not paste production secrets into an untrusted device merely because the HMAC Generator keeps processing in the current browser tab.
Verification belongs on the server and should compare tags with a constant-time function. A matching result demonstrates shared-key and byte consistency, not message confidentiality. Anyone who obtains both the message and the secret can read the plaintext and forge a new valid tag.