Skip to content
TypeParser
All tools

HMAC Generator

HMAC-SHA1/256/384/512.

beats freeformatter.com edge: All hash variants in parallel
message
type message
Guide

About HMAC Generator

Compute HMAC of any message with a shared secret. SHA-1, SHA-256, SHA-384, and SHA-512 variants all computed in parallel. Output as hex or Base64. Useful for webhook signature verification, API request signing (AWS SigV4 style), and any scheme that proves a message was signed by a party holding the shared secret.

What HMAC adds over plain hash

A keyed hash. Without HMAC, anyone seeing the hash can verify the message. With HMAC, only parties holding the shared secret can produce or verify the hash. That property is the foundation of webhook signing, API request authentication, signed cookies, and most lightweight authentication schemes.

The construction is roughly hash((key XOR opad) || hash((key XOR ipad) || message)) — designed to resist length-extension attacks that plain hash(secret || message) is vulnerable to.

Common HMAC use cases

SystemAlgorithmWhere the signature lives
Stripe webhooksHMAC-SHA-256Stripe-Signature header
GitHub webhooksHMAC-SHA-256X-Hub-Signature-256 header
Shopify webhooksHMAC-SHA-256X-Shopify-Hmac-Sha256 header
AWS SigV4HMAC-SHA-256Authorization header
Slack signingHMAC-SHA-256X-Slack-Signature header
JWT HS256HMAC-SHA-256inside the JWT

Common workflows

Verify a webhook locally. Paste the secret, paste the raw body, compare the resulting HMAC against the header. Match → genuine; mismatch → reject.

Sign an outbound request. Build the canonical string per your provider’s docs, paste here, compute HMAC, attach to header. Match the byte sequence exactly — newlines, encoding, all matter.

Debug a signature mismatch. Compute the HMAC against multiple candidate canonical strings until one matches. Most webhook bugs are subtle string-construction differences (raw vs parsed body, header order, line endings).

Why constant-time comparison matters

When verifying a signature server-side, compare with constant-time equality (crypto.timingSafeEqual in Node, hmac.compare_digest in Python). Naive == short-circuits on the first different byte — measurable timing differences leak the correct signature one byte at a time. The HMAC tool here is for development; in production, always use the timing-safe primitive.

Frequently asked questions

When do I need HMAC instead of plain hash?
When verification requires the secret. Plain sha256(message) reveals nothing useful — anyone can compute it. hmac_sha256(secret, message) can only be reproduced by parties holding the secret, so the recipient can verify provenance.
Hex or Base64 output?
Hex is the default for inspection (each byte → 2 chars). Base64 is more compact and is what webhook headers usually use. Pick what your system expects.
How long should the secret be?
At least as long as the hash output (32 bytes for SHA-256). Shorter secrets get padded; longer secrets get pre-hashed. Generated random secrets from the Random String tool work well.
How does Stripe / GitHub webhook signing work?
They send X-Signature with HMAC-SHA-256 of the raw body using a secret you set in their dashboard. Compute the same HMAC on receipt; constant-time-compare. Match → trust the payload.
Is the secret leaked anywhere?
No. Computation runs in the browser via Web Crypto. The secret and message stay client-side.
What about SHA-3 / BLAKE3?
Web Crypto supports SHA-1/256/384/512 only. BLAKE3 and SHA-3 need a JS library and are not the typical choice for HMAC.

Related tools

Last updated: 2025-01-15