HMAC Generator — SHA-256, SHA-512
Generate HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 message authentication codes using a secret key. Verify API signatures, webhook payloads, and JWT secrets. Output in hex or Base64. Runs entirely in your browser.
Message
Secret Key
HMAC Signature — HMAC-SHA256
Verify HMAC (paste expected signature)
Pro — HMAC key derivation, batch signing, JWT builder, API access
API access · Priority queue · Team workspace
How It Works
Enter Message & Key
Enter the message (the data to authenticate — a request body, a payload, a URL query string) and the secret key (a shared secret known to both the sender and the receiver). Both are encoded as UTF-8 bytes before hashing. Click Sample to load a demo message and key pair that you can use to verify your HMAC implementation produces the same output as this tool.
Select Algorithm & Format
Choose HMAC-SHA1, HMAC-SHA256 (most common), HMAC-SHA384, or HMAC-SHA512. Select Hex or Base64 output format — APIs typically specify which format they expect (GitHub webhooks use hex, Stripe uses hex, AWS Signature v4 uses hex, many JWT libraries use Base64). Toggle UPPERCASE for systems that require uppercase hex. The signature updates instantly as you type.
Copy or Verify
Copy the generated HMAC signature and use it in your API request, webhook handler, or authentication header. To verify an incoming signature, paste the expected HMAC into the Verify field — the tool compares it to the computed value and shows a match or mismatch badge. Comparison is case-insensitive and handles both hex and Base64.
HMAC Generator Features
Keyed message authentication for API signing, webhook verification, and JWT
What is HMAC?
HMAC (Hash-based Message Authentication Code) is a method for verifying both the data integrity and authenticity of a message using a shared secret key. Unlike a plain hash (which anyone can compute), an HMAC requires knowing the secret key — so only parties with the key can produce or verify it. HMAC is defined in RFC 2104 and is the authentication mechanism behind HMAC-SHA256 in JWTs, AWS Signature V4, GitHub/Stripe webhooks, and Slack event verification.
Webhook Signature Verification
Many services (GitHub, Stripe, Shopify, Twilio, Slack) sign webhook payloads with HMAC-SHA256 using a shared secret. When your server receives a webhook, it recomputes the HMAC and compares it to the signature in the request header. Use this tool to debug webhook signatures during development: paste the raw payload and your webhook secret, select HMAC-SHA256, and compare the output to the X-Hub-Signature-256 or similar header value.
Hex & Base64 Output
Toggle between hex (lowercase or uppercase) and Base64 output formats. Hex is the most common format for API signatures — GitHub uses sha256=hexdigest, Stripe uses t=timestamp,v1=hexdigest. Base64 is used in JWT HMAC signatures (alg: HS256) where the signature is Base64url encoded. The tool provides both without recalculating the underlying bytes.
Web Crypto API
HMAC computation uses the browser's native crypto.subtle.sign('HMAC', ...) API with crypto.subtle.importKey() for the secret key. This is the same cryptographic implementation used by the browser for HTTPS and WebAuthn, and produces output identical to Python's hmac.new(key, msg, hashlib.sha256).hexdigest(), Node.js crypto.createHmac('sha256', key).update(msg).digest('hex'), and OpenSSL's openssl dgst -sha256 -hmac.
Signature Verification
Paste an expected HMAC signature in the Verify field to compare it against the computed value. The comparison uses a constant-time-style string comparison to detect matches regardless of case. This is useful for debugging authentication failures — enter your message, key, and the failing signature to confirm whether the mismatch is a key issue, a message encoding issue, or an algorithm mismatch.
100% Private
Your secret key and message are never transmitted to any server. All HMAC computation runs locally using the browser's Web Crypto API. Safe for testing production webhook secrets, API signing keys, and JWT secrets without exposing them to a third-party service. Disconnect from the internet and the tool continues to function — confirming there is no server dependency or telemetry.
Free vs Pro
| Feature | Free | Pro |
|---|---|---|
| HMAC-SHA1/256/384/512 | ||
| Hex & Base64 output + verify | ||
| Batch message signing | — | |
| JWT HS256/384/512 builder | — | |
| AWS Signature V4 helper | — | |
| REST API access | — |
Frequently Asked Questions
A plain hash (SHA-256, MD5) takes only the message as input — anyone with the message can compute the same hash. HMAC takes the message AND a secret key — only someone with the key can compute the correct HMAC. This makes HMAC suitable for authentication: a server sends a message signed with its secret key, and the receiver verifies the signature by recomputing the HMAC with the same key. If the signature matches, the message is genuine and unmodified.
GitHub sends a header X-Hub-Signature-256: sha256=<hex> with each webhook request. To verify: paste the raw request body as the message, paste your webhook secret as the key, select HMAC-SHA256, set output to Hex. The result should match the hex value in the header (after the sha256= prefix). If it matches, the webhook is genuine. If it does not match, check that you are using the raw body bytes (not parsed JSON) and the correct secret.
A JWT with algorithm HS256 (or HS384, HS512) uses HMAC-SHA256 (or 384/512). The message is base64url(header) + "." + base64url(payload) and the secret is your JWT signing key. The HMAC is computed over that string, then Base64url-encoded to form the signature segment. To verify a JWT: reconstruct the header.payload string, recompute the HMAC with your secret key in Base64 format, and compare it to the signature segment. Use the JWT Decode tool to inspect the header and payload.
HMAC-SHA256 is the current recommended standard and the most widely supported algorithm. HMAC-SHA1 should only be used when required by a legacy system — SHA-1's weaknesses are less relevant for HMAC (where the key prevents preimage attacks), but SHA-256 is preferred for new systems. HMAC-SHA512 offers higher security margin at the cost of slightly longer signatures and is used in high-security applications. HMAC-SHA384 is a truncated version of SHA-512, used in some TLS cipher suites.
HMAC operates on bytes, not characters. The string "hello" encoded as UTF-8 and the same string encoded as Latin-1 produce identical bytes for ASCII characters — but differ for non-ASCII characters (é, ü, 中). This tool encodes both the message and the key as UTF-8. If your system uses a different encoding, the HMAC values will differ. Also check that you are not including a trailing newline in your key or message — a trailing \n changes the HMAC completely.
Yes — your key and message are never transmitted to any server. All computation happens locally in your browser using the Web Crypto API. The key is passed to crypto.subtle.importKey() and exists only in memory during computation. You can verify by opening browser developer tools, going to the Network tab, and confirming that typing in the key field generates no network requests. Safe to use with production webhook secrets and API signing keys.