Pick a scheme, paste the raw body, signature header, and secret, then select Verify signature. A passing GitHub-style example is loaded so you can try it right away.
About the webhook signature debug lab
The webhook signature debug lab recomputes a webhook's HMAC-SHA256 signature from the raw body and your signing secret, then compares it to the signature your provider sent. When they do not match, it explains the usual reasons: the raw body was re-serialized before verifying, the wrong secret or environment was used, the timestamp is outside the replay tolerance, or the signature encoding does not line up. It covers the Stripe style (t=, v1= with a timestamp check), the GitHub style (X-Hub-Signature-256), and a generic HMAC-SHA256 mode that accepts hex or base64.
Pick a scheme, paste the raw request body, the signature header, and the signing secret, then select Verify signature. A passing GitHub-style example is loaded so you can see a clean result right away, and a failing Stripe-style example shows a valid signature that is still rejected because its timestamp is stale. Everything runs in your browser with the Web Crypto API. The payload, header, and secret are never uploaded or stored. You can copy a debug note or download a verification checklist to keep working through a failure.
How to use
- Choose the signature scheme that matches your provider: Stripe style, GitHub style, or generic HMAC-SHA256.
- Paste the raw request body exactly as it was received, before any re-serialization.
- Paste the signature header value and the signing secret. The secret stays masked until you choose to show it.
- Select Verify signature to recompute the HMAC and compare it to the provided signature.
- Read the result and reasons. Select Copy debug note for a markdown summary, or Download checklist to work through a failed verification.
Worked examples
GitHub-style sample verifies
The preloaded GitHub example uses a body and secret whose X-Hub-Signature-256 matches, so it returns Verified with no reasons.
Stripe-style sample fails on the timestamp
The preloaded Stripe example has a correct v1 signature but a timestamp far in the past, so it is rejected for being outside the 300 second tolerance even though the signature itself is valid.
A reformatted body no longer verifies
Adding a trailing newline or re-serializing the JSON changes the bytes the HMAC is taken over, so the recomputed signature stops matching even with the right secret.
Frequently asked questions
- Which signature schemes does the lab support?
- Three at first ship: the Stripe style (a Stripe-Signature header of t=<unix>,v1=<hex> where the signed payload is the timestamp, a dot, then the raw body, plus a timestamp tolerance check), the GitHub style (X-Hub-Signature-256: sha256=<hex> over the raw body), and a generic HMAC-SHA256 mode that takes the header as the signature and accepts hex or base64. All three use HMAC-SHA256.
- Why does my signature fail even though the secret is right?
- The most common cause is the raw body. An HMAC is taken over exact bytes, so if your framework parsed and re-serialized the JSON, changed whitespace or key order, or changed the charset, the recomputed signature will not match. Verify against the raw body your server received, not a reformatted copy. For the Stripe style, also check the timestamp is within tolerance, since a valid signature is still rejected as a replay when the timestamp is too old.
- Is my payload or secret sent anywhere?
- No. The lab computes the HMAC in your browser with the Web Crypto API. The payload, header, and signing secret are never uploaded, logged, or stored, and the debug note and checklist you export contain only the result, the scheme, short non-sensitive signature previews, and the reasons. Close the tab and nothing is kept.
- Can I use this to secure my production endpoint?
- No. This is a debugging aid for working out why a signature does or does not verify. It is not a hardened, constant-time production verifier and must not gate real request handling. Use your provider's official server-side SDK or a vetted verification routine in production.
- What can I keep from a session?
- Copy debug note gives you a markdown summary of the result, scheme, signature previews, and reasons to paste into an issue, a runbook, or a pull request. Download checklist gives you a short, provider-aware list of the things to check when a verification fails. Neither export contains your secret or the full raw body.
Use this again tomorrow
Save this page so it's one tap away when you need a quick result.
Ready for a quick Daily Challenge?
Play Daily Challenge on sts.games