Generate an HMAC — Free HMAC-SHA1/256/384/512 Generator

When you need to prove that a message arrived exactly as it was sent — and that it came from someone who holds the same secret — an HMAC generator gives you a cryptographic guarantee in seconds. Unlike a plain checksum or a bare hash, the resulting hmac signature binds your payload to a shared private key, enabling both payload signing and sender confirmation in a single compact token. Whether you are protecting a webhook endpoint, authenticating a service request, or building a token-based scheme, understanding how to generate and validate hmac online is a foundational skill in modern cryptography.

What Is an HMAC Signature Generator and How Does It Work?

HMAC stands for hash-based message authentication code — sometimes written as keyed-hash message authentication code. It is a cryptographic technique standardised in RFC 2104 that layers a secret cryptographic key on top of a standard cryptographic hash function (such as SHA-256, SHA-384, SHA-512, SHA-1, or MD5) to produce a fixed-length output that simultaneously proves content validity and sender origin. Because the private key is mixed into the computation, only a party that possesses the same shared value can produce or confirm the same tag — this is what separates HMAC from a plain hash.

The formal construction involves three components: the message (the data you want to authenticate), the key (a shared value between sender and receiver), and the hash function (the underlying method). The initialization step chooses both the hash method and a key K. During key modification, if the key is longer than the hash function's block size, it is hashed down to fit; if it is shorter, key padding brings it up to the block size with zero bytes. Two derived keys are then produced by XOR-ing the padded key against a fixed inner padding constant (ipad, 0x36 repeated) and a fixed outer padding constant (opad, 0x5C repeated). The full formula is:

In plain language: first, the inner pass concatenates the ipad-derived key with your message content and hashes the result into an intermediate output. Then, the outer pass concatenates the opad-derived key with that intermediate value and hashes again, producing the final authentication code. This double-pass construction is deliberately resistant to length-extension attacks that can compromise simpler MAC designs, making HMAC a robust mac method for production use.

HMAC vs. Plain Hash vs. MAC — Key Differences Involving SHA-256 and Beyond

A plain hash (SHA-256, and legacy functions such as SHA-1 or MD5) is a one-way function anyone can compute from the message alone. It confirms that the content has not been altered, but it offers zero confirmation of origin: an attacker who intercepts and replaces a message can simply recompute a fresh hash to match. A generic MAC method requires a key but may lack the standardised security proof that HMAC carries. HMAC bridges both gaps: it provides message integrity through keyed processing and origin confirmation through the shared value, making it the standard choice for service request protection, webhooks, and token signing (HS256, HS384, HS512).

Common real-world applications include service request validation (attaching an hmac-sha256 output of the path plus a timestamp to each outbound call), webhook payload signing (Stripe, GitHub, and Slack all use HMAC to let your server confirm that an incoming webhook genuinely came from the platform), signed cookies protecting session data from client-side tampering, and token schemes where the HS256 method (HMAC-SHA256) covers the header-plus-payload pair. The shared private value is the linchpin: as long as only the sender and receiver possess it, a valid tag is proof of both origin and content validity.

Worked Examples: Service Signing, Webhook Validation, and JWT with the HMAC Signature Generator/Verifier

The three worked examples below demonstrate hmac calculation in concrete, step-by-step form so you can trace exactly how the hash and hmac calculator derives each result. All examples use HMAC-SHA256 and produce hex output unless stated otherwise. These cover the most common developer scenarios: service request signing, webhook payload validation, and building the signature component of a JWT. This free online tool runs the same computation automatically as you type.

Example 1 — Service Request Signing with HMAC-SHA256

Scenario: your application must add a content-validation tag to each outbound REST call so the receiving server can confirm the request was not modified in transit. This is a classic request-signing workflow common across developer tools and service integrations.

1. Identify the message: concatenate the HTTP method, path, and JSON body into a canonical string — for example, POST /orders {"amount":99,"currency":"USD"}. This is your plain-text format input.
2. Set the private key: use a 32-byte cryptographically random value, e.g. s3cr3tK3y!2024xYz — keep it confidential in your application configuration and never commit it to source control.
3. Select the method: choose HMAC-SHA256 (HS256) in the hmac generator tool.
4. Compute the tag: the tool produces a hex output such as 9946dad4e00e913fc8be8e5d3f7e110a4a9e832f83fb09c345285d78638d8a0e — your hmac output.
5. Attach the tag: send it as an X-Signature-HMAC-SHA256 request header. The server-side logic recomputes it identically and compares; if they match, the request is confirmed as authentic.

The formula executed internally during this hmac calculation is:

Example 2 — Webhook Payload Validation (Incoming Webhook from an External System)

Scenario: you operate a server endpoint that receives incoming webhook POST requests from a webhook provider — for instance, a Stripe webhook, GitHub webhook, or Slack webhook. Each request carries a tag header; your job is to confirm that the payload has not been altered by an external system or a man-in-the-middle before processing payloads.

1. Read the raw body: capture the exact byte sequence of the HTTP request body — {"event":"payment.completed","id":"evt_001"}. Do not parse JSON first; whitespace differences will break the content check.
2. Retrieve the shared key: your private value agreed with the provider during registration. Treat it as confidential information.
3. Compute the tag: paste the body and the shared key into the tool and select SHA-256. The tool performs automatic computation and shows the hex output.
4. Compare tags: use recomputation logic on the server and compare your computed value against the value in the X-Hub-Signature-256 (GitHub) or Stripe-Signature header using a constant-time comparison to prevent timing attacks. A mismatch means either the body was modified or the wrong key was used — the payload was potentially tampered with.

This webhook validation pattern — recompute on arrival, then compare — stops replay attacks and forgeries because any change to the payload changes the output entirely, and only a holder of the private value known to both sides can produce a matching tag. It is the confirmation scheme used across nearly all major service platforms.

Example 3 — JWT HS256 Signature Component

Scenario: you are building or debugging a JWT token (JSON Web Token) that uses the HS256 method — HMAC-SHA256. The tag covers the encoded header and payload so that any tampering with the token body invalidates the token. JWT also uses HS384 and HS512 (HMAC with SHA-384 and SHA-512, respectively) for larger outputs.

1. Encode header and payload: base64url-encode the JSON header {"alg":"HS256","typ":"JWT"} and the payload {"sub":"user_42","iat":1700000000} separately, then join with a dot: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzQyIiwiaWF0IjoxNzAwMDAwMDAwfQ.
2. Set the private key: use your application's token-signing key — store it in secrets management and rotate it on a schedule.
3. Generate HMAC online: paste the dot-joined string as the message and your key into the hmac generator/verifier. Select HMAC-SHA256 and set output to base64url encoding.
4. Append the tag: the base64url-encoded output forms the third segment of your JWT — header.payload.<hmac-output>. This is the signed message that a receiving server can confirm by recomputing over the first two segments with the shared key.

In JWT terminology, HS256 maps directly to HMAC-SHA256; HS384 maps to HMAC-SHA384; HS512 maps to HMAC-SHA512. The message output calculation is identical to the standalone HMAC case — only the representation of the input and the output format differ. Use a dedicated JWT & JWE Debugger or JWK generator alongside this tool when building full token flows involving SAML, TOTP, passkey, or WebAuthn.