JoyToolsJoyTools

HMAC Signature Generator

100% Client-Side Private — Zero Server Uploads

Generate and verify HMAC signatures (HMAC-SHA256, HMAC-SHA512) for Stripe, GitHub, Shopify, and Webhook verification.

🔒 100% Client-Side: All data is processed locally in your browser and never leaves your device (Zero Server Uploads).
E-E-A-T Security Proof →
Interactive Workspace
Platform:
Algorithm:
Format:
X-Webhook-Signature (SHA-256 / HEX)
Enter secret key to compute signature...

Verify Received X-Webhook-Signature Header

Share & Developer Embed

How do I use HMAC Signature Generator?

1

Select your HMAC digest algorithm (`HMAC-SHA256`, `HMAC-SHA512`, `HMAC-SHA384`, `HMAC-SHA1`, or `HMAC-MD5`) and output encoding (`Hex` or `Base64`).

2

Enter your Payload Message and Secret Key, or click 'Sample' to load a realistic webhook signature test.

3

Copy the computed HMAC signature to verify Stripe, Shopify, GitHub, or JWT webhook headers.

What features does HMAC Signature Generator offer?

Browser-native Web Crypto API calculation (HMAC-SHA256, HMAC-SHA512, HMAC-SHA1)

Hex and Base64 output formats

Live Webhook Signature Verifier with comparison matching status

100% client-side privacy guarantee — secret keys never leave browser

RFC 2104 Keyed-Hash Message Authentication Code (HMAC) Formula

HMAC prevents length-extension attacks on Merkle–Damgård hash functions (like SHA-256) by hashing the secret key with an inner pad (`0x36`) and outer pad (`0x5c`) in two nested passes.

Webhook & API Providers Using RFC 2104 HMAC Signatures
Provider / StandardAlgorithmOutput EncodingHTTP Signature Header Format
GitHub WebhooksHMAC-SHA256Hexadecimal (lowercase)X-Hub-Signature-256: sha256=<hex>
Stripe WebhooksHMAC-SHA256Hexadecimal (lowercase)Stripe-Signature: t=<ts>,v1=<hex>
Shopify WebhooksHMAC-SHA256Base64 StandardX-Shopify-Hmac-Sha256: <base64>
JWT HS256 / HS512HMAC-SHA256 / 512Base64URL (no padding)Header.Payload.<base64url_sig>

Frequently Asked Questions about HMAC Signature Generator

Why use `HMAC-SHA256(key, message)` instead of simply hashing `SHA256(key + message)`?

Naive `SHA256(secret + message)` constructions are vulnerable to length-extension attacks, where an attacker who knows `SHA256(secret + message)` and the length of `secret` can append malicious data and compute a valid hash without knowing the secret key. RFC 2104's double-hash `opad`/`ipad` construction eliminates this vulnerability.

Why doesn't my computed HMAC match the signature sent by Stripe or Shopify?

Webhook HMACs must be computed over the exact raw UTF-8 HTTP request body bytes before `JSON.parse()` re-serializes whitespace. Also check whether the provider encodes the digest as lowercase `Hex` (GitHub, Stripe) or `Base64` (Shopify).

Why must backend servers compare HMAC signatures using `crypto.timingSafeEqual`?

Standard string equality (`a === b`) returns `false` on the first mismatched byte, leaking timing side-channel information that lets attackers guess signatures byte-by-byte. Always use constant-time comparison in production.

Is my API secret key ever transmitted to a server when generating an HMAC here?

Never. All HMAC calculations run 100% locally in your browser memory.