Free webhook tester. Inspect HTTP requests live.

Paste a JSON payload, x-www-form-urlencoded body, or URL query string into the inspector below and see it validated and pretty-printed in real time. No login, no rate limit, no telemetry — the entire tool runs in your browser, so paste production payloads without worrying about logs.

Want a public URL like splitforms.com/webhook-test/abc123 that captures real incoming webhooks? That ships next — join the waitlist below.

{
  "event": "submission.created",
  "delivery_id": "dlv_2BcDeFgHiJkLmNoPqRs",
  "timestamp": "2026-05-04T18:22:11.482Z",
  "form": {
    "id": "frm_a1b2c3d4",
    "name": "Contact form",
    "access_key": "ak_redacted_in_payload"
  },
  "submission": {
    "id": "sub_9zYxWvUtSrQpO",
    "received_at": "2026-05-04T18:22:11.299Z",
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_5)",
    "referrer": "https://example.com/contact",
    "spam_score": 0.04,
    "data": {
      "name": "Jane Builder",
      "email": "jane@example.com",
      "message": "Hello — interested in the Pro plan for our agency."
    }
  }
}

Privacy note: this inspector is rendered as a static page with one client component. It performs no network requests, sets no cookies, and includes no analytics on the inspector itself. You can verify this in your browser's DevTools Network panel — typing in the textarea triggers zero outbound traffic.

How webhooks work (and why they break)

A webhook is an HTTP POST request sent from one server to another when an event happens. When a customer pays you on Stripe, Stripe issues a POST to a URL you configured, with a JSON body describing the event. When someone opens a pull request on GitHub, GitHub does the same. Webhooks are how the modern web glues services together without polling — instead of your server asking "anything new yet?" every thirty seconds, the upstream service simply tells you the moment something changes.

The contrast with a traditional API is push versus pull. With a REST API your code initiates every request: you call GET /v1/charges and Stripe answers. With a webhook the direction is reversed: Stripe calls POST https://yourapp.com/webhooks/stripe with the new charge. You still need an API for queries, but you need a webhook for real-time notifications without infrastructure cost on either side.

Webhooks fail for predictable reasons. The receiving server is down, slow, or returns a 5xx — so the sender retries, often with exponential backoff, which means the same event can be delivered two, five, or fifteen times. The signature header is calculated over the raw body, but a middleware (a body parser, a logging proxy, a load balancer) re-serializes JSON before your handler sees it, so the signature no longer matches and verification fails. The TLS handshake times out because the sender has a 10-second limit and your handler does synchronous work that takes 11. The event arrives out of order — a charge.refunded shows up before the corresponding charge.succeeded, and your code crashes because it can't find the charge to refund. Each of these is a normal Tuesday for a webhook integration; robust handlers anticipate every one of them.

Debugging webhooks well comes down to four habits. First: log every incoming request with its raw body and full header set, indexed by the provider's delivery ID, so you can replay anything you missed. Second: respond with 200 OK as soon as you've persisted the request, then do the real work in a background queue — synchronous handlers create timeouts and timeouts create duplicate deliveries. Third: verify the signature against the raw bytes before doing anything else; never trust an unsigned webhook in production. Fourth: make every handler idempotent — the same event ID processed twice should produce exactly the same result, because it will happen.

The inspector above helps with the first half of debugging: making sure the body you think you're receiving is the body you actually are. Paste a captured payload, confirm it parses, confirm the keys match what your code reads. The second half — replay, retry, signature verification — needs a backend, which is what splitforms ships for outbound webhooks on every plan.

What a webhook tester actually tests

The phrase "webhook tester" covers two slightly different tools. The first kind is a public-URL capture service — you register a unique address with a sender (Stripe, GitHub, Shopify, Mailchimp), and the service shows you each request as it arrives, including headers, query string, body, and source IP. The second kind is a payload inspector: you already have a sample request (from a logfile, your provider's dashboard, a colleague's paste), and you want to validate the structure without writing code. The page you're on does the second; the public URL ships next.

The two are complementary. In a typical debugging session you capture a real request with a public-URL service so you have a reproducible sample, then you paste that sample into an inspector to confirm the body shape, then you write a unit test that pins the parsed structure so future regressions show up immediately. Most webhook bugs in production are not transport bugs — TLS, DNS, and HTTP have been working fine for years — they are schema bugs: the field you expected was renamed, the timestamp moved from seconds to milliseconds, the array became a single object on a low-cardinality response. An inspector is the fastest way to catch those.

Reading a signed webhook header

Every reputable webhook is signed. A typical signed header looks like t=1714867200,v1=5257a869e7ec… — the t field is a unix timestamp the sender produced just before sending, and v1 is a hex-encoded HMAC of the timestamp concatenated with the raw body, using a shared secret you configured on the sender. The timestamp exists so a captured request can't be replayed an hour later by an attacker who sniffed your traffic — a typical handler rejects anything older than five minutes. The signature itself proves both authenticity (only the sender knows the secret) and integrity (any byte changed in the body breaks the HMAC). You compute the same HMAC on receive, compare with crypto.timingSafeEqual, and you're done.

Common webhook formats

A quick reference for the most common providers. The inspector handles every body type below; signature verification still happens server-side in your handler.

Why use splitforms for webhooks?

If you also need to sendwebhooks — every form submission forwarded to your backend, Slack, Discord, or a custom URL — splitforms handles delivery, retries, and replay so you don't build it yourself.

• Signed on every plan

  Every outbound webhook is signed with HMAC-SHA256 over the raw body, sent in X-Splitforms-Signature. No upgrade required.

• Exponential-backoff retries

  Failed deliveries retry seven times over 24 hours: 30s, 2m, 10m, 30m, 2h, 6h, 24h. Configurable per webhook.

• Dead-letter queue + replay

  Webhooks that exhaust retries land in a dead-letter UI in your dashboard. One click replays them once your endpoint is fixed.

• Auto-detected flavors

  Slack-style and Discord-style webhook URLs are detected automatically and re-shaped to match each platform's expected payload schema.

• Per-form secrets

  Rotate the signing secret per form without touching other integrations. Old secret has a 24-hour grace window for safe migration.

• Free tier included

  All webhook features are on the free 1,000-submissions/month plan. No surprise paywall when traffic ramps up.

Webhook tester FAQ

Send signed webhooks from every form, free.

1,000 submissions a month, every month, with HMAC-signed delivery, seven-attempt retries, and a dead-letter replay UI. No credit card.