HMAC Generator — SHA-1 / SHA-256 / SHA-384 / SHA-512

Real-world use cases

• Verify a Stripe / payment-provider webhook signature by hand

  A webhook isn't firing your handler and you suspect the signature check. Grab the raw request body from your logs, paste it as the message, take the webhook signing secret (Stripe's `whsec_...` is UTF-8 text), choose HMAC-SHA256, and compare the hex output against the `t=...,v1=...` value in the `Stripe-Signature` header. If they match, your verification code has a bug (often it re-parsed the JSON, changing the bytes); if they don't, you're using the wrong secret or signing the wrong payload. Either way you've isolated the problem in two paste operations instead of redeploying with print statements.

• Build the X-Signature header your client has to send

  You're integrating with an API that requires every request to carry `X-Signature: <hmac of the body>`. Paste your request body as the message, paste the API key the provider gave you, pick the algorithm their docs specify, and copy the hex (or base64 — read their docs) tag straight into your test in Postman or curl. This lets you confirm the exact tag the server expects before you wire the signing into your code, so you debug the HMAC step in isolation rather than tangled up with auth and routing.

• Check the signature segment of a JWT HS256 token

  A JWT is being rejected as "invalid signature" and you want to know whether the signature itself is wrong or something upstream is. Take the token's `header.payload` (the first two dot-separated segments, base64url) as the message, paste the HS256 secret, choose HMAC-SHA256, and compare the base64 output against the token's third segment (after converting base64url `-_` to base64 `+/`). If they match, the signature is fine and the problem is claims or expiry; if not, the secret or the signing input differs.

• Reproduce a GitHub webhook delivery for testing

  GitHub signs webhook payloads with HMAC and sends `X-Hub-Signature-256: sha256=<hex>`. To replay a delivery against your local server, copy the exact JSON payload as the message, paste your webhook secret as a UTF-8 key, pick HMAC-SHA256, and prepend `sha256=` to the hex output to recreate the header. Now you can curl your endpoint with a signature it will actually accept, without waiting for GitHub to send a real event.

• Diagnose a hex-vs-base64 or key-encoding mismatch

  Two systems agree on the secret but disagree on the tag. Paste the shared message and key, then toggle the key encoding between UTF-8, hex, and base64 and watch the byte-length readout: a 32-byte random key stored as 64 hex chars decodes to 32 bytes under "hex" but to 64 bytes under "UTF-8", producing two entirely different tags. Flip between the hex and base64 outputs too — if one side compared base64 while the other compared hex, the tags "differ" only because they're different encodings of the same bytes.

Common pitfalls

• Signing the wrong bytes. HMAC is over the raw message exactly as sent — if you re-serialize a JSON body, re-order keys, or add/strip a trailing newline before signing, you get a different tag than the sender did. Always sign the byte-for-byte payload, not a reconstructed object.

• Misreading the key encoding. A 32-byte key written as 64 hex characters is NOT the same as that 64-character string treated as UTF-8 text — they decode to different bytes and different tags. Match the key mode (UTF-8 / hex / base64) to how the other side encoded the secret, and use the byte-length readout to confirm.

• Comparing different output encodings. hex and base64 are two encodings of the identical tag bytes; if your code base64-decodes the expected value but you paste the hex form (or vice versa) the comparison fails for no cryptographic reason. Pick the encoding the receiver actually compares against.

Privacy