HMAC Generator Online — SHA-256, SHA-512 + Base64
HMAC generator online — sign payloads with SHA-256, SHA-512, SHA-384, SHA-1. Hex / Base64 / Base64URL output. Webhook + JWT HS256 ready. No signup.
The secret never leaves your browser. PDFFlare cannot see, store, or transmit it.
Enter both a secret and a message above to compute the HMAC.
PDFFlare's HMAC generator online signs any payload with any standard HMAC algorithm in seconds. Use it as an hmac sha256 generator for Stripe, GitHub, Slack, and Shopify webhook signatures. Use it as an hmac sha512 generator for JWT alg HS512 tokens. Use it as a webhook signature generator when building or debugging a webhook receiver. Or use it as an hmac calculator online for AWS Signature v4 derived-key chains (run four HMAC-SHA-256 stages, paste each result into the secret for the next).
Three things make this dedicated tool more powerful than a generic hash tool: (1) secret format toggle — decode your key from text, hex, or base64 without manual conversion; (2) output format toggle — get the digest in lowercase hex (Stripe, AWS), UPPERCASE hex (Microsoft world), Base64, or Base64 URL (JWT) without a second tool; (3) generate random key mints a fresh 256-bit signing secret in your chosen format. Pair with the JWT Decoder to inspect tokens you sign, or with the Hash Generator for non-keyed text hashing, or with File Checksum for download integrity verification.
Computation runs entirely in your browser via Web Crypto's crypto.subtle.importKey() and crypto.subtle.sign(). The secret never leaves the page, never reaches a server, never lands in a log. Safe for development webhook secrets, JWT signing keys, and any payload you wouldn't paste into a third-party debugger. RFC 4231 test vectors verified.
How to Generate HMAC Signatures
Pick the algorithm
HMAC-SHA-256 for Stripe, GitHub, Slack, JWT HS256, and AWS Signature v4 — that's the modern default. HMAC-SHA-512 for JWT HS512. HMAC-SHA-384 for HS384. HMAC-SHA-1 only for legacy compatibility (older Twilio, AWS Signature v2). The ? button next to the selector shows what each algorithm is and where it's used.
Pick the secret format
Text for plain UTF-8 webhook secrets (Stripe and GitHub both use this). Hex for keys stored as hexadecimal strings. Base64 for keys in base64 encoding. The tool decodes the secret bytes correctly so you don't have to convert formats by hand. Or click "Generate random key" to mint a fresh 256-bit key.
Paste the message
The exact bytes the sender hashed. For Stripe webhooks: timestamp.body. For GitHub: just the body. For Slack: v0:timestamp:body. The construction is provider-specific and the source of most signature mismatches — see the FAQs for each provider's recipe.
Pick the output format and copy
Lowercase hex is what Stripe + GitHub + AWS expect. UPPERCASE hex matches Microsoft conventions. Base64 covers some legacy webhook headers. Base64 URL is for JWT signatures (the bytes that go after the second dot). The HMAC updates live as you type; click Copy to put the digest on your clipboard.
When Do You Need an HMAC Generator Online?
Verifying webhook signatures (Stripe, GitHub, Slack, Shopify): Your endpoint receives a webhook with a signature header that doesn't match what your code computes. The fastest way to debug is to compute the HMAC manually here, side by side with what your code produces, and find which one drifted. Paste the body, paste the secret, pick the algorithm, get the signature. Mismatch always points at the construction (timestamp prefix? raw body? wrong secret?).
Signing JWTs (alg HS256, HS384, HS512): JWT signatures in the HS family are HMAC over the base64url-encoded header.payload joined by a dot. Compute the HMAC with this tool, set output format to Base64 URL, and you have the signature bytes. Append after a third dot for a complete signed JWT. Useful for hand-crafting test tokens or verifying that your auth library produces the digest you expect.
AWS Signature v4 derived signing key: AWS Signature v4 chains four HMAC-SHA-256 calls to derive its signing key. Compute each stage in this tool: HMAC of date with `AWS4`+secret as the key, then HMAC of region with that result, then service, then `aws4_request`. Paste the result of each stage into the secret field for the next stage (set secret format to hex). Whichever stage produces a different digest from your code is where the bug lives.
Building a webhook receiver from scratch: You're writing a new webhook integration and need to verify your code's output against a known-good implementation. Use this hmac calculator online as the reference: paste the same body + secret your code is processing, compute the expected digest, compare. Same pattern for any custom HMAC pipeline — Discord bots, internal service mesh signing, idempotency-key signing, SaaS integrations.
Why Use PDFFlare's HMAC Generator?
Four Algorithms + Four Output Formats
HMAC-SHA-1, SHA-256, SHA-384, SHA-512 covering every modern provider. Output as lowercase hex, UPPERCASE hex, Base64, or Base64 URL — no second tool needed to convert.
Secret Format Decoder
Toggle between text, hex, and base64 secret encodings. The tool decodes your key bytes correctly so you don't have to do the conversion in a separate step. Plus a one-click random-key generator for fresh signing secrets.
100% Browser-Based
Web Crypto handles the HMAC math natively. Your secret and your payload never leave your machine — safe for production webhook secrets and JWT signing keys.
No Signup Required
Free, unlimited, no account, no rate limits. Bookmarkable for the next time a webhook integration breaks at 2 AM. Algorithm + format choices persist across sessions via localStorage (the secret is never stored).
Frequently Asked Questions About HMAC Generator
SHA-256 is a one-input hash — paste a string, get a 256-bit digest anyone can reproduce. HMAC-SHA-256 is two-input — paste a message AND a secret key, get a 256-bit digest only someone with the same secret can reproduce. Webhooks use HMAC because the secret proves the message wasn't forged. SHA-256 alone can't do that.
HMAC-SHA-256 for nearly everything in 2026 — Stripe, GitHub, Slack, Discord, Shopify, JWT HS256, AWS Signature v4. HMAC-SHA-512 for JWT HS512 or when you specifically need a longer digest (often slightly faster on 64-bit servers). HMAC-SHA-384 for JWT HS384. HMAC-SHA-1 should only be used for legacy compatibility — newer code should never choose it.
Three usual suspects. (1) You parsed the JSON body before hashing — Stripe hashes the raw bytes including their exact whitespace and key order. Capture the raw body before parsing. (2) You forgot the timestamp prefix — Stripe's signed payload is `{timestamp}.{body}`, not just the body. (3) Wrong endpoint secret — endpoint secrets and webhook signing secrets aren't the same in Stripe; use the secret for the specific endpoint that received the request.
GitHub sends `X-Hub-Signature-256: sha256=<hex>`. The message is the raw HTTP body — no timestamp prefix, no provider string. Compute HMAC-SHA-256 of the body with your webhook secret. Common bugs: (1) using the older X-Hub-Signature (HMAC-SHA-1) header instead of the SHA-256 variant, (2) parsing the JSON before hashing, (3) wrong webhook secret (each repo or org webhook has its own).
Slack signs `v0:<timestamp>:<raw-body>` with HMAC-SHA-256 using your signing secret. The output goes in `X-Slack-Signature` as `v0=<hex>`. Common bugs: forgetting the v0: prefix, using colons instead of dots, parsing the JSON body. Also reject any request older than 5 minutes (compare the timestamp header against current time) for replay protection.
JWT HS256 = HMAC-SHA-256 over base64url(header).base64url(payload), joined by a dot. Paste that string as the message, your signing key as the secret, pick HMAC-SHA-256, set output format to Base64 URL, and you have the JWT signature. Append it after a third dot and you have a valid signed JWT. For full token construction, a JWT library is usually easier — but this tool is great for verifying that your library produces the same signature you compute manually.
Browser Web Crypto exposes HMAC for SHA-1, SHA-256, SHA-384, and SHA-512 only. HMAC-MD5 is deprecated for security use and any system that still requires it can be implemented from MD5 plus the standard HMAC construction. For new code use HMAC-SHA-256 — it's better-supported, faster on modern CPUs, and not subject to MD5's collision weaknesses.
Most webhook providers store secrets as plain text (Stripe's `whsec_...`, GitHub's webhook secret string). Some advanced systems store keys in hex or base64 — like KDF-derived keys, AWS API secrets, or anything where the bytes aren't printable text. The toggle decodes the secret you paste correctly without you having to convert it manually first. Pick the format your secret is currently in.
Different providers want the digest in different encodings. Hex (lowercase) is the modern default — Stripe, GitHub, AWS Signature v4. UPPERCASE hex appears in some Microsoft-world systems. Base64 shows up in older webhook designs and some Asian-market providers. Base64 URL is for JWT signatures (the part after the second dot). Same digest bytes, four representations.
Yes. The HMAC computation runs entirely in your browser via Web Crypto's importKey() and sign(). Your secret never leaves the page, never goes to PDFFlare's servers, isn't logged anywhere. The Show / Hide toggle exists so you can paste in incognito and never have the plain secret visible on screen. Safe for development webhook secrets and short-lived signing keys.