Encoders & Utilities

Webhook Tester

Generate a unique URL, send any HTTP request to it, and inspect the captured method, headers, query, and body live in your browser.

Privacy notice

Anyone with the bin URL can see all requests sent to it. Do not use for production secrets. Bins auto-delete after 24 hours of inactivity and only keep the 10 most recent requests.

How it works

All HTTP methods are accepted (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS).
Text bodies are stored up to 10 KB; larger bodies are truncated. Binary bodies (images, files, octet-stream) are replaced with a 1 KB stub plus SHA-256 of the original.
A bin keeps the 10 most recent requests; older entries are dropped automatically (FIFO).
Bins live for 24 hours after their last activity. View opens, receive hits, all reset the timer.
Recognized signature headers (GitHub, Stripe, Slack, Shopify, Twilio) are highlighted, but never verified — we do not know your secret.

About this tool

Webhook Tester gives you a one-click public URL that captures any HTTP request sent to it — method, headers, query parameters, body (text or binary), timestamps, and source IP. The URL stays alive for 24 hours; requests stream into your browser in real time via Server-Sent Events, so you see incoming hits the moment they land without polling. Each unique URL is private (a 128-bit random token in the path), so only the people you share it with can post to it.

Everything captured is shown side-by-side: raw request line, headers, parsed query, body with auto-detection of JSON / XML / form-encoded / plain text. Headers like X-Hub-Signature, Stripe-Signature, or any HMAC-style verification can be inspected to debug signing schemes. You can also configure the response — change the status code, add response headers, or send a JSON body — to simulate the production endpoint and confirm your producer handles non-2xx responses correctly.

When to use this tool

Integrating with third-party APIs. Stripe, GitHub, Twilio, Slack — every one of them needs a public callback URL to develop against; this tool gives you one without setting up tunnels.
Debugging webhook payloads. See the exact bytes the sender produces, headers and all, before writing your own consumer.
Testing retry behaviour. Set the response to 500 and confirm the producer retries; flip to 200 and confirm it stops.
Reproducing an issue. Capture a failing webhook payload, then replay it from a curl-equivalent into your local dev server.

About persistence and privacy

Captured requests are stored for 24 hours and then deleted. The URL itself remains active during that window — share with care, since anyone who has it can post anything to it. For sensitive integrations (production payment webhooks), use a tunnel-to-localhost tool (ngrok, cloudflared tunnel) instead — that keeps payloads entirely on your local machine. This tool is for development and testing, not for real production traffic.

Frequently asked questions

How long does my webhook URL stay active?

24 hours from creation. Captured requests are kept for the same window and then auto-deleted. If you need a longer-lived URL, re-create it from the same page (it gives you a fresh token) and update the sender. For permanent integrations, host a tiny endpoint yourself or use a tunnelling tool that targets your local dev server.

Can I see incoming requests in real time?

Yes — the page subscribes to Server-Sent Events (SSE) from our backend, so each new request appears in the table as it arrives, typically within milliseconds. Refresh the page if needed; the history is also persisted server-side for the 24h window so a reload gets the full list.

Is this safe for production webhook secrets?

No — captured payloads sit on our servers for 24 hours and could be read by us in principle. For production webhooks containing secrets (Stripe payment events, GitHub repository tokens), use a tunnel-to-localhost tool (ngrok, cloudflared tunnel) so the payload never leaves your laptop. This tool is for dev / staging / one-off debugging of test events.

Can I customize the response?

Yes — set the status code (200, 201, 204, 4xx, 5xx), add response headers (e.g. Content-Type: application/json), and write a response body. Useful for confirming your producer handles error responses correctly. Many webhook senders retry on 5xx; configuring a 500 here is the easiest way to verify the retry behaviour without touching production code.