What is the difference between HMAC-SHA-256 and a plain SHA-256 hash?

A plain SHA-256 hash is a one-way digest that anyone can compute. HMAC-SHA-256 combines the same hash with a secret key, so only parties who hold the key can produce a matching tag. Use HMAC for authentication, plain SHA-256 only for non-secret integrity checks.

Which SHA-2 variant should I pick for a new API integration?

Pick the variant the documentation specifies. For modern REST APIs and JWTs that is usually HMAC-SHA-256. Choose SHA-512 when you want the largest tag size or when the spec explicitly says HS512.

Can I enter my key as hex instead of UTF-8 text?

Yes. The HMAC Generator lets you set the key and the message to UTF-8 or hexadecimal independently. Use hex when the secret was distributed as raw bytes and UTF-8 when the secret is a readable string.

Should I copy the tag as hex or Base64?

Copy whichever format the receiving protocol expects. Most webhook signatures use lowercase hex; JWT HS256/384/512 signatures and many AWS-style headers use standard Base64 with padding. Do not truncate the tag unless the spec asks for a shorter value.

Is HMAC safe for storing passwords?

No. HMAC is intentionally fast, which makes brute-force attacks against hashed passwords cheap. Use a slow, salted KDF such as Argon2id, scrypt, bcrypt, or PBKDF2 for password storage.

Does the tool send my key or message to a server?

No. The HMAC Generator runs entirely in your browser, so the key and the message never leave your device. You can verify this by working offline after the page has loaded.

How to Generate an HMAC: SHA-256, SHA-384 and SHA-512

An HMAC (Hash-based Message Authentication Code) is a fixed-length cryptographic tag produced by combining a secret key with a hash function — most commonly SHA-256, SHA-384, or SHA-512 — over an exact byte sequence of a message. The result is 256, 384, or 512 bits long depending on the chosen SHA-2 variant, and it lets the receiver verify that the message was written by someone who knows the key and was not altered in transit. Generating an HMAC means picking a SHA-2 variant, supplying the key and the message as precise bytes, and copying the resulting tag as hex or Base64 in the format the destination protocol expects.

Most searchers who type "how to generate HMAC" are doing one of three things: signing an outgoing API request, checking the format of a signature that already arrived, or building a webhook verifier for a payment or messaging provider. All three jobs share the same recipe, and the fastest way to get an exact, protocol-ready tag is to use the HMAC Generator, which runs entirely in your browser and accepts both UTF-8 text and raw hex bytes for the key and the message. The pages that follow break down what HMAC actually is, where it fits among other encodings, and how to produce a correct tag in three short steps.

What HMAC Is and When to Use It

HMAC is defined in RFC 2104 and formalised for SHA-2 in RFC 4868. Internally it runs the chosen hash function twice — once over a key-derived inner pad and once over an outer pad that wraps the message digest — which is why the construction is considered secure as long as the underlying hash is collision-resistant. SHA-1 HMAC (HMAC-SHA-1) is still widely deployed in legacy APIs such as older AWS signatures and OAuth 1.0a flows, but new designs should pick one of the SHA-2 variants.

The tag is deterministic: the same key and the same message bytes always produce the same tag. That property is what makes HMAC useful for:

API request signing — including AWS Signature Version 4, Stripe webhooks, Slack signing secrets, and many custom REST APIs.
Webhook verification — the sender includes an HMAC tag in a header, and the receiver recomputes it with the shared secret.
Message authentication in protocols — TLS exporters, JWTs signed with HS256/HS384/HS512, and IPsec ESP use HMAC under the hood.
File or firmware integrity checks — when both parties already share a key out of band.

HMAC is not for password hashing. A password verifier must be intentionally slow and salted; an HMAC tag is fast by design. For passwords, use a memory-hard KDF such as Argon2id, scrypt, bcrypt, or PBKDF2. The How to Generate a Password Hash the Easy Way guide covers that workflow separately.

Choosing Between HMAC-SHA-256, SHA-384, and SHA-512

The three SHA-2 variants differ only in output length and the number of internal compression rounds. In practice the choice is dictated by the receiving protocol rather than by performance, because all three are fast on modern hardware.

Variant	Output length	Common use cases
HMAC-SHA-256	256 bits (32 bytes, 64 hex chars)	JWT HS256, Stripe webhooks, AWS SigV4 (derived), most modern REST APIs
HMAC-SHA-384	384 bits (48 bytes, 96 hex chars)	TLS 1.2 cipher suites that prefer SHA-384, some government and finance integrations
HMAC-SHA-512	512 bits (64 bytes, 128 hex chars)	JWT HS512, high-assurance integrations, environments where SHA-512 is already accelerated

If the API documentation says "sign with HMAC-SHA-256" or shows a sample tag that is 64 hex characters, pick HMAC-SHA-256. If it says HS512 or shows 128 hex characters, pick HMAC-SHA-512. The HMAC Generator lets you switch between the three without re-entering your inputs, which is useful when a spec is ambiguous and you want to see which output matches the expected sample.

Key and Message Encoding: UTF-8 vs Hex

The single most common reason an HMAC tag comes out "wrong" is that the key or message bytes did not match what the server hashed. A printable-looking string is not always UTF-8 — it could contain invisible characters, a stray newline, or non-ASCII code points that change the byte sequence. A hex key such as 0a1b2c3d is also not the same thing as the ASCII characters "0a1b2c3d".

The HMAC Generator treats the key and message independently. For each field you can switch between two modes:

UTF-8 — the field is encoded as standard UTF-8 bytes. Use this when the documentation says "the secret is the string abc123" or when copying a value from a configuration screen.
Hex — the field is parsed as raw hexadecimal bytes. Use this when the documentation shows bytes like 4b 65 79 21, when the secret was generated by an HSM, or when copy-pasting a key from a hex dump.

When entering hex, type the bytes as a continuous string with optional spaces — for example 4b 65 79 21 or 4b657921. The tool validates the input and reports any odd-length or non-hex characters rather than silently substituting a replacement. If you need to inspect or convert raw bytes first, the Hex to Text Converter and the UTF-8 Encoder / Decoder handle the conversion without uploading anything.

How to Generate an HMAC Step by Step

Open the HMAC Generator and pick the algorithm that matches the receiving protocol — SHA-256, SHA-384, or SHA-512. The default is HMAC-SHA-256, which is the most common choice for modern REST APIs.
Choose the encoding for the key — UTF-8 if the secret is human-readable text, or Hex if it was distributed as raw bytes. Enter the exact value with no leading or trailing whitespace; a hidden newline will change the tag.
Choose the encoding for the message independently. Most APIs sign a canonical string such as timestamp + "." + body, so paste that assembled string as UTF-8.
Generate the tag and review the length — 64, 96, or 128 hex characters. If it does not match the expected sample from the documentation, double-check the algorithm and the byte encoding before suspecting the tool.
Copy the tag in the requested format — Hex for headers such as Stripe's Stripe-Signature body, or standard Base64 for protocols that wrap the tag in JWT-style signatures. Do not truncate unless the spec explicitly says so.

If the output has to be embedded in JSON or a URL query string, a Base64 tag may need additional encoding. For URL-safe contexts the URL Decoder handles percent-encoding without losing the underlying value. For an internal integrity check rather than a remote signature, the Checksum Calculator covers lighter-weight XOR-8 and Modbus LRC values when the protocol does not need cryptographic strength.

Reading the Output and Common Pitfalls

Hex output uses lowercase a–f by convention and is byte-aligned — 64 hex chars for HMAC-SHA-256, 96 for HMAC-SHA-384, 128 for HMAC-SHA-512. Base64 output follows RFC 4648 with padding, so it ends in one or two = characters; if the receiving side rejects "invalid base64", the most likely cause is missing padding or the wrong alphabet (URL-safe vs standard).

Three mistakes account for almost every "my HMAC does not match" report:

Extra whitespace — trailing spaces, tabs, or a final newline in the key or message. Use a hex view to confirm the byte count if a discrepancy persists.
Wrong case for hex — most verifiers accept upper or lower case, but a few custom implementations compare byte-for-byte. Keep the output exactly as the tool produces it.
Encoding mismatch — the server treats the secret as ASCII while the client treats it as UTF-8, or vice versa. The fix is to match the server's documented byte interpretation.

When the tag still does not match after those checks, regenerate using the same algorithm on a known input — for example key key and message The quick brown fox jumps over the lazy dog produce a fixed HMAC-SHA-256 value that is easy to look up. If that known input also fails, the key encoding is almost certainly the problem.

HMAC, Plain Hashes, and Authenticated Encryption

A plain SHA-256 digest — generated by tools like the SHA256 Hash Generator — confirms that a message has not changed, but it does not prove who wrote it, because anyone can recompute a plain hash. HMAC adds the secret key so only parties who hold the key can produce a valid tag. That is why token-based APIs almost always use HMAC rather than a bare SHA-256.

For full confidentiality plus authentication in a single operation, an authenticated cipher such as AES-256-GCM is the standard tool. The AES Encryption Online page covers that workflow when the requirement is to keep the message itself secret rather than just sign it. For password-derived keys, the Password Generator can produce a high-entropy secret to feed into HMAC, and the Password Strength Checker gives transparent feedback on length and obvious patterns before you commit a key to production.