Webhook Signature Verifier
Free online tools to verify webhook signatures. Pick a provider below to check a signature against your secret with the exact scheme that provider uses — or use the generic HMAC generator. Everything runs in your browser: the payload and secret never leave the page, and there’s no signup.
Verify Stripe signatures
→Validate the Stripe-Signature header against your endpoint signing secret.
Verify GitHub signatures
→Validate the X-Hub-Signature-256 header against your webhook secret.
Verify Shopify signatures
→Validate the X-Shopify-Hmac-Sha256 header against your app's API secret.
Verify Slack signatures
→Validate the X-Slack-Signature header against your app's signing secret.
Verify Twilio signatures
→Validate the X-Twilio-Signature header for form-encoded webhook callbacks.
Verify Standard Webhooks signatures
→Validate the webhook-signature header used by the Standard Webhooks spec.
Don’t see your provider? Most webhooks use plain HMAC over the request body — use the HMAC generator & signature verifier (SHA256, SHA512, SHA1, MD5) for any of them.
What is a webhook signature?
A webhook signature is a cryptographic fingerprint a provider attaches to each webhook so you can prove the request really came from them and wasn’t altered in transit. The provider and you share a secret; the provider computes a hash — almost always HMAC‑SHA256 — over the request body (sometimes prefixed with a timestamp and id) and sends the result in a header such as Stripe-Signature, X-Hub-Signature-256 or webhook-signature. You recompute the same hash with your copy of the secret and compare. If they match, the webhook is authentic; if not, you reject it. Without this check, anyone who learns your endpoint URL could POST fake events to it.
Schemes differ in the details — which header carries the signature, whether the output is hex or base64, whether a timestamp is included to stop replay attacks, and how the secret is encoded — which is why a Stripe verifier and a Shopify verifier aren’t interchangeable. The tools above bake in each provider’s exact rules so you don’t have to.
How to verify a webhook signature
- Capture the raw request body before any JSON parsing — re-serializing changes the bytes and breaks the hash.
- Read the signature (and timestamp/id, if used) from the provider’s headers.
- Recompute the HMAC with your shared secret using the provider’s exact construction.
- Compare with a constant-time comparison (e.g.
crypto.timingSafeEqual), and reject stale timestamps to block replays.
Frequently asked questions
How do I verify a webhook signature?
Recompute the provider's HMAC over the raw request body (plus any timestamp/id it signs) using your shared secret, then constant-time compare it to the signature header. Pick your provider above to do it instantly, or read the step-by-step above.
Why must I use the raw request body?
Providers sign the exact bytes they send. Parsing JSON and re-serializing it changes whitespace and key order, so the recomputed hash won't match. Always verify against the unparsed body.
What is a replay attack and how do timestamps help?
A replay attack resends a previously valid, correctly-signed webhook. Providers that sign a timestamp (Stripe, Slack, Standard Webhooks) let you reject requests older than a few minutes, which defeats replays.
Is this safe to paste secrets into?
Yes — every verifier here runs entirely in your browser with the Web Crypto API. Your payload and secret are never sent to a server, and no signup is required. Still, prefer test secrets where you can.