HMAC Generator with SHA-256, SHA-384 and SHA-512

How to generate an HMAC

Enter the shared secret and message exactly as the protocol defines them, select the required SHA-2 algorithm and output encoding, then generate. Both fields are encoded as UTF-8 bytes. Even a single whitespace or encoding difference produces a different authentication code.

1. Paste the secret key. Use the exact raw text only when the protocol specifies a UTF-8 text key; do not paste a Hex or Base64 key without decoding it first.
2. Paste the data exactly, including line endings, separators, timestamp text and any canonical JSON representation required by the protocol.
3. Choose SHA-256, SHA-384 or SHA-512 and the expected Hex or Base64 representation.
4. Generate and compare the complete code through the protocol’s verification process. Clear the key and clipboard when finished.

Examples and expected behavior

What HMAC provides

HMAC is a standardized message authentication construction that combines a secret key with a cryptographic hash function. A verifier who possesses the same secret can recompute the code and detect changes to the message. Unlike a plain hash, an attacker who sees only the message and HMAC should not be able to create a valid code for a modified message without the key.

HMAC provides integrity and shared-secret authenticity; it does not encrypt the message or hide its content. Anyone who can view the payload can still read it. It also does not provide non-repudiation because every holder of the shared key can generate the same code. Use digital signatures when verification must work with a public key and the signer must be distinguishable.

• HMAC-SHA-256 uses SHA-256 inside the HMAC construction.
• The output length matches the underlying hash output.
• Confidentiality requires separate encryption.

Key representation and key management

This page treats the key field as UTF-8 text. If a protocol gives a key in hexadecimal or Base64, those characters are often an encoding of raw key bytes rather than the literal text key. Using the encoded characters directly produces a different HMAC. Decode the key according to the protocol before using a tool that expects raw bytes, or use an implementation with an explicit key-encoding option.

Security depends heavily on key entropy, storage and rotation. Human passwords are usually poor HMAC keys unless a proper key-derivation function is specified. Store production keys in a secret manager or protected platform facility, limit access, rotate them and define key identifiers for verification during transitions. Never commit keys to source control or paste them into support tickets.

• Use protocol-generated random keys, not memorable words.
• Distinguish raw bytes from Hex and Base64 text.
• Plan rotation and revocation before deploying webhook authentication.

Canonical message bytes and UTF-8

Both key and data are encoded with TextEncoder as UTF-8. HMAC authenticates bytes, not abstract objects. Different line endings, whitespace, Unicode normalization, property order, URL encoding or timestamp formatting produce different results. When a protocol signs JSON, it usually defines an exact canonical string or raw request body; reformatting the JSON before verification can break the signature.

Capture the exact bytes or exact textual construction named by the protocol. Join fields with the specified separators, preserve leading zeros and do not convert seconds to milliseconds unless instructed. If the message includes a body hash, compute that hash from the original body bytes. Most HMAC integration failures are canonicalization mismatches rather than cryptographic failures.

• CRLF and LF are different byte sequences.
• A trailing newline changes the HMAC.
• Visually identical Unicode can have different normalization forms.

Algorithm and output encoding

The page supports HMAC with SHA-256, SHA-384 and SHA-512. Choose the exact algorithm required by the API, webhook provider or test vector. HMAC-SHA-256 is widely used and is a sound default when designing a new interoperable scheme with expert review. HMAC-SHA-384 and HMAC-SHA-512 produce longer outputs and may be mandated by specific standards.

Hex and Base64 are only encodings of the resulting bytes. A verifier expecting lowercase Hex will not match a Base64 string, even though both could represent the same code. Some protocols use Base64url rather than standard Base64; this page outputs standard Base64 with +, / and padding. Convert only when the protocol explicitly specifies another alphabet.

• HMAC-SHA-256 output is 32 bytes.
• Hex comparison may be case-insensitive, but follow the protocol.
• Standard Base64 is not the same as Base64url.

Webhook and API verification workflow

HMAC commonly protects webhooks and signed API requests. A robust verifier reads the raw request body, extracts the timestamp and key identifier, reconstructs the exact signed message, computes HMAC with the selected secret and compares codes in constant time. It also enforces a timestamp tolerance and records replay identifiers where appropriate.

This browser page is useful for test vectors and debugging, but it is not a production webhook endpoint. Do not expose a server secret in a shared browser session merely to make a comparison. Prefer local development secrets or synthetic vectors. In production, verification belongs on the trusted server boundary before the payload triggers business actions.

• Verify before parsing or mutating the raw signed body when the protocol requires raw bytes.
• Reject stale timestamps to reduce replay risk.
• Use constant-time comparison to avoid timing leaks.
• Select the correct secret by key ID during rotation.

Errors, limits and secure handling

An empty key is rejected because it is almost always a mistake, although the HMAC specification can technically process one. Web Crypto must be available. The current implementation holds the key and message in page state only for the active page and does not intentionally write them to logs, localStorage, session storage or IndexedDB. Clearing the form removes the page values but cannot erase clipboard-manager history or screen recordings.

The tool accepts text fields, not arbitrary binary keys or files. It does not derive keys from passwords, truncate tags, compare tags in constant time or manage nonce and replay state. Those decisions belong to the protocol implementation. For highly sensitive production secrets, use a local audited command-line tool or application environment where the key never enters a general browsing session.

• Do not paste live production secrets into shared or managed devices.
• Clear clipboard contents after copying sensitive test material.
• Do not truncate an HMAC unless the protocol defines an analyzed tag length.

How this differs from a plain hash and encryption

A plain SHA hash has no secret, so anyone can compute it for any candidate message. It can detect accidental changes only when the expected digest is trusted through another channel. HMAC adds a shared secret and is designed to resist extension and collision-related pitfalls that arise from naive constructions such as hash(key || message).

Encryption hides content but does not automatically authenticate it unless an authenticated-encryption mode is used correctly. HMAC authenticates content but leaves it readable. Modern protocols often use authenticated encryption or separate encryption and authentication with carefully derived keys. Do not invent a custom combination from browser outputs; follow a reviewed standard.