Does HMAC-SHA256 encrypt my message?

No. HMAC authenticates the exact message bytes with a shared secret but does not conceal the message. Anyone who sees the message can read it, and anyone who learns the key can forge valid tags.

Why does my HMAC tag differ from another tool’s output?

Check the hash algorithm, key bytes, message encoding, whitespace, newline convention, tag truncation, and whether the other tool uses Base64url instead of standard Base64. Even a single byte difference changes the tag.

Can I use a password as the HMAC key?

A human password is usually low entropy. Use the protocol’s required password-based key derivation function (PBKDF2, Argon2, scrypt, etc.) with the exact parameters, or generate a strong random key instead of improvising.

What happens if I enter an odd number of hex digits?

The HMAC Generator rejects odd nibbles in hex mode to prevent silent byte changes. Hexadecimal input must have an even number of digits—no prefixes, spaces, or colons allowed.

Is the HMAC calculation performed on the server?

No. The HMAC Generator uses the browser’s Web Cryptography API, so the calculation happens locally in your tab. No inputs are sent to a server, and the key material never leaves your device.

What is the maximum size for the key or message?

The page limits each decoded field to 1,000,000 bytes. Larger inputs are rejected so an accidental paste of a huge file cannot freeze the browser or produce misleading output.

HMAC-SHA256 Tag Generator: Hex and Base64 Guide

An HMAC-SHA256 tag is a 32-byte cryptographic fingerprint that proves a message originated from a party who knows the same secret key. Unlike a plain SHA-256 hash, HMAC binds the key into every step of the hash calculation, so an attacker who sees the message cannot forge a valid tag without the key. This property makes HMAC ideal for API request signatures, file integrity checks, and short-lived tokens. The HMAC Generator tool produces the exact tag your protocol expects by letting you enter the key and message as UTF-8 text or raw hexadecimal bytes, choose SHA-256, SHA-384, or SHA-512, and receive the full output in lowercase hex or standard Base64—all without uploading data to a server.

When you need to sign an API payload, verify a firmware update, or authenticate a JWT, the protocol specification tells you which hash to use, whether the key and message are UTF-8 strings or binary blobs, and how to encode the final tag. For example, AWS Signature Version 4 requires HMAC-SHA256 with UTF-8 keys and messages, while a firmware manifest might use HMAC-SHA512 with hex-encoded binary data. The HMAC Generator matches these requirements by giving you independent UTF-8 or hex input modes, so you can paste the exact bytes your protocol defines without accidental formatting changes. The tool also locks correctness to eight RFC 4231 test vectors, ensuring that short keys, repeated-byte data, and block-boundary crossings all produce the expected tags.

generate hmac sha256 — HMAC-SHA256 Tag Generator: Hex and Base64 Guide

What HMAC Actually Does—and What It Does Not

HMAC combines a cryptographic hash with a shared secret key. A verifier that possesses the same secret and exact message bytes can calculate the same tag, which can detect modification and authenticate the party that knew the key. It does not, however, hide the message. Anyone who sees plaintext can still read it, and anyone who learns the key can forge valid tags. This distinction is essential: HMAC answers the question “did the holder of this secret produce this exact byte sequence?”—it does not answer “can I keep this message confidential?” If you need both properties, pair HMAC with an authenticated encryption scheme or use a protocol that bundles confidentiality with integrity, such as AES-GCM, ChaCha20-Poly1305, or libsodium’s secretbox.

Byte identity is essential. Text mode encodes both fields as UTF-8, so accented letters, CJK characters and emoji occupy multiple bytes. Hex mode accepts only an even number of hexadecimal digits and preserves every byte, including zero. It rejects prefixes, spaces, colons and odd nibbles so an accidental formatting character cannot silently change a protocol value. The selected hash changes tag length: SHA-256 returns 32 bytes, SHA-384 returns 48, and SHA-512 returns 64. This page always displays the full output. A protocol may require truncation, a prefixed algorithm identifier, a canonical request string, a binary envelope or Base64url rather than standard Base64. Apply those rules only from the protocol specification; do not trim a tag by eye.

When to Use SHA-256, SHA-384, or SHA-512

HMAC-SHA256 is the most widely deployed variant because it balances security and performance. SHA-256’s 32-byte output provides strong collision resistance while remaining compact enough for HTTP headers, database columns, and embedded systems. SHA-384 and SHA-512 offer higher security margins and produce longer tags—48 and 64 bytes—which can bloat storage and bandwidth. Use SHA-384 or SHA-512 only when the protocol explicitly requires them, such as in environments that mandate FIPS-approved algorithms at higher security levels, or when the extra collision resistance matters for long-term archives. The generator exposes all three options so you can match the governing protocol exactly.

Hash	Tag Length (bytes)	Hex Characters	Base64 Characters	Typical Use Case
HMAC-SHA-256	32	64	44	API signatures, JWT, webhooks
HMAC-SHA-384	48	96	64	FIPS-approved modules, long-lived secrets
HMAC-SHA-512	64	128	88	Firmware manifests, high-security tokens

Generate HMAC Tags Step by Step

Open the HMAC Generator in your browser.
Select the hash algorithm: SHA-256, SHA-384, or SHA-512. Confirm that your protocol expects the full tag length—do not truncate unless the specification explicitly requires it.
Choose the input encoding for the key and message independently. UTF-8 mode encodes text as UTF-8 bytes, while hex mode accepts only an even number of hexadecimal digits (no prefixes, spaces, or colons).
Enter the secret key and message as exact bytes. For UTF-8, paste the raw text; for hex, paste the continuous hex string. The tool rejects odd nibbles and formatting characters to prevent silent byte changes.
Click “Generate HMAC” to compute the tag. The result appears in lowercase hex and standard padded Base64. Copy the encoding your protocol requires—do not convert or truncate unless the specification instructs you to.
Compare the full tag with the expected value. Byte identity is critical: a single bit difference means the key or message bytes do not match.

Common Input Pitfalls and How to Avoid Them

HMAC tags are sensitive to every byte in the key and message. A single invisible change—such as a trailing newline, a Unicode normalization difference, or an accidental space—produces a completely different tag. The HMAC Generator prevents many of these mistakes by rejecting malformed hex input and preserving exact UTF-8 encoding. However, some pitfalls still require attention before you click generate:

Whitespace and newlines: If your protocol defines the message as a JSON payload or a canonical request string, ensure you include the exact whitespace and line endings the specification requires. The tool treats every byte literally, so a missing newline or an extra space changes the tag.
Unicode normalization: UTF-8 mode encodes text as-is, so “café” with an acute e and “cafe” followed by a combining acute accent produce different bytes. Use the same normalization form (NFC or NFD) that the verifier uses.
Hex formatting: Hex mode accepts only continuous hexadecimal digits. Prefixes like “0x”, separators like colons or spaces, and odd nibbles are rejected. If your key or message is published with formatting, remove it before pasting.
Empty fields: Empty keys and messages are rejected by the interface to prevent accidental clicks, even though some low-level standards can define behavior for zero-length data. If your protocol genuinely requires an empty field, confirm the spec’s exact rules first.
Key entropy: A human password is not automatically a strong HMAC key. If the protocol allows a password, use its required password-based key derivation function (PBKDF2, Argon2, scrypt, etc.) with the exact parameters. The HMAC Generator does not derive keys—it expects the final byte string.

When debugging a mismatched tag, start by confirming the hash algorithm, key bytes, and message bytes. Use hex mode to rule out encoding differences, and compare the full tag in hex to eliminate Base64 padding or URL-safe variations. The Base64 to Hex Converter can help translate between encodings if the protocol expects one but the tool outputs the other. Remember that hex and Base64 are only renderings of identical tag bytes—decoding either into raw bytes must yield exactly the same value before any comparison.

How the HMAC Generator Ensures Correctness and Security

The HMAC Generator uses the browser’s native Web Cryptography API to perform the HMAC calculation. The key and message bytes are imported as a non-exportable HMAC key with SHA-256, SHA-384 or SHA-512, and the subtle.sign method returns the full tag without truncation. This approach ensures that the calculation happens locally in your browser tab—no data is sent to a server, and the key material never leaves your device. Asynchronous jobs carry an identity token, so changing input while Web Crypto is working prevents an older result from overwriting the new state.

Correctness is locked to eight RFC 4231 test vectors, which cover short keys, binary repeated-byte keys and data, keys smaller than the digest, and data crossing hash block boundaries. SHA-256 and SHA-512 are checked for four independent inputs each, while the interface also exposes the WebCrypto-defined SHA-384 option. These test cases guarantee that the generator produces the same tags as other compliant implementations, so you can trust the output for production use.

Security depends on the key material and surrounding practices. The tool enforces a 1,000,000-byte limit per decoded field to prevent accidental large inputs, but it does not validate key entropy or distribution. Use independently generated high-entropy key material appropriate for the protocol, distribute it through a protected channel, separate keys by purpose, rotate after compromise, and compare tags with a constant-time function on the server. When a password must become a key, follow the exact password-based derivation scheme and parameters required by the application. The Password Generator can create strong random material locally if your protocol allows raw secrets, but always avoid pasting production secrets into an untrusted device.

Protocol-Specific Adjustments After Generating the Tag

The HMAC Generator always outputs the full tag in lowercase hex and standard padded Base64. Many protocols require additional steps before the tag can be transmitted or stored. Apply these adjustments only after the HMAC itself has been calculated correctly, and only according to the protocol specification:

Truncation: Some specifications ask for a shorter tag than the full hash output. Truncate only after generating the full tag—do not change the HMAC calculation itself. Truncate to exactly the byte count specified, never by visual length.
Algorithm identifiers: JWT and some API signatures prepend the algorithm name to the tag, such as “sha256=” or an explicit “HS256” header. Add these identifiers only when the protocol requires them—do not include them in the HMAC calculation, because they would change the message bytes.
Base64url encoding: JWT and other web protocols use Base64url, which omits padding and replaces “+” with “-” and “/” with “_”. Convert the standard Base64 output to Base64url only when the specification instructs you to. The HMAC Generator does not emit Base64url directly to avoid confusion with standard Base64, and the two encodings are not interchangeable—decoding them produces different bytes.
Binary envelopes: Some protocols package the message and tag together in a binary format, such as a protobuf or a custom header. Extract the tag from the generator’s output and insert it into the envelope according to the protocol’s rules.
Canonical request strings: Many signing protocols first assemble a canonical string from headers, payload and timestamp. Generate the HMAC over that exact canonical string, not over the raw request body, and use the key bytes the protocol prescribes.

Successful agreement between two HMAC tags proves shared key and byte consistency, not message confidentiality. Store and transmit each field according to the protocol, since visually similar encodings are not interchangeable. Use the generator only after identifying the exact bytes and algorithm from the governing protocol, prefer hex mode for published vectors and binary fields, and remember that the tool is a calculation aid—key management, transport security, and verifier implementation remain the responsibility of your application.