Webhook Tester: Signed Payloads, Sent for Real
Testing a webhook receiver usually means either waiting for a real event from a third-party service, or hand-crafting a curl command with a manually-computed signature. This tool does both steps for you — compute a real HMAC-SHA256 signature over your test payload, then send it directly to your endpoint via a real POST request, so you can verify your handler's logic end-to-end.
Requests are sent via the browser's fetch() — your receiving endpoint must allow cross-origin requests (CORS) for the response to be readable.
Testing Signature Verification Logic
Most webhook integration bugs live in the signature-verification step — an off-by-one in header parsing, a mismatched secret, or comparing against a re-serialized payload instead of the raw bytes. Sending a genuinely signed test payload to your local development server lets you confirm your handler accepts valid signatures and rejects invalid ones, without waiting for a real third-party event.
Why the Signature Header Name Is Configurable
Different providers use different header names for their signature (X-Hub-Signature-256, Stripe-Signature, X-Webhook-Signature, and many custom variants) — letting you set the exact header name means this tool can produce a payload matching whatever convention your own webhook handler expects.
Practical Examples
Testing a Local Webhook Handler
Verifying your Express/Flask/etc. handler's signature check works.
- 1.URL: http://localhost:3000/webhooks (CORS-enabled)
- 2.Enter your handler's expected secret
- 3.Send, and confirm your handler accepts the signed payload
What Gets Sent
- A POST request with your JSON payload as the body
- Content-Type: application/json
- An HMAC-SHA256 signature header (if a secret is provided)
Good Use Cases
- Testing webhook signature verification in local development
- Confirming a handler correctly rejects tampered payloads
- Reproducing a webhook delivery without waiting for a real event
- Debugging a webhook integration end-to-end
Frequently Asked Questions
How is the signature computed?
Using the Web Crypto API to compute a real HMAC-SHA256 digest of your exact payload with the secret you provide, formatted as sha256=
Why does this need a URL I control?
Requests are sent directly from your browser via fetch(), which enforces CORS — your receiving endpoint needs to explicitly allow cross-origin requests (or be running locally where you control that configuration) for the browser to let this tool read the response.
Can I test signature verification logic in my webhook handler?
Yes — that's the main use case: send a payload with a correctly-computed signature to your local development server, and confirm your handler's HMAC verification logic accepts it (then try tampering with the payload or secret to confirm it correctly rejects invalid signatures too).
What if my receiver expects a different signature format than sha256=<hex>?
This tool currently generates the GitHub-style sha256=
Is my data sent anywhere besides my target URL?
No — the request goes directly from your browser to the URL you specify; nothing is proxied or logged by this tool.