Webhook / HTTPリクエストテスター
ブラウザからHTTPリクエストを構築して送信し、レスポンスを詳細に確認します。
このツールについて
任意のHTTPリクエストを構成してください — メソッドを選択し、URLを入力し、プリセットショートカットを使用してカスタムヘッダーを追加し、リクエストボディを記述してから「送信」ボタンで実行します。レスポンスパネルにはステータスコード、レスポンスヘッダー、レスポンスがJSONの場合は整形されたボディが表示されます。レスポンス時間はミリ秒単位で計測され、最後の5つのリクエストがlocalStorageに保存されて素早く再実行できます。
使い方
- 1 HTTPメソッド(GET、POST、PUT、PATCH、DELETE)を選択してターゲットURLを入力してください。
- 2 キーと値のエディタを使用して必要なヘッダーを追加してください。一般的なヘッダーのプリセットを使用できます。
- 3 POST/PUT/PATCHリクエストの場合は、ボディを入力してContent-Typeを選択してください。
- 4 「送信」をクリックして、レスポンスパネルでステータスコード、ヘッダー、ボディを確認してください。
What this tool actually does
This is an HTTP request builder that sends a real network request from your browser and shows you the full response. You pick a method (GET, POST, PUT, PATCH, DELETE), type a URL, optionally add headers and a request body, and press Send. Under the hood it calls the browser's standard fetch() API, so the request leaves your machine and travels to the server you named — this is not a simulation, and the URL and any data you send go to that endpoint. The response status, headers, body, and round-trip time come back and are displayed, with JSON automatically pretty-printed.
The CORS reality you must understand
Because the request originates from a web page, it is governed by the browser's same-origin policy and CORS (Cross-Origin Resource Sharing) rules. When you call an API on a different domain than this site, the browser only hands you the response if that server explicitly opts in by returning an Access-Control-Allow-Origin header that permits the request. If the server does not, the browser blocks the response and you get a network/CORS error — even though the server may have received and processed the request. The tool detects this case and shows a hint that it is "likely a CORS error."
This is a browser limitation, not a bug. It means this tester works perfectly against:
- APIs that are CORS-enabled (many public REST and testing APIs are);
- your own server, once you add the right CORS headers;
- any endpoint behind a proxy you control that adds CORS headers.
For testing arbitrary third-party APIs that lack CORS, a desktop client like curl or a server-side script is the right tool, because those are not bound by browser CORS.
A worked example
Select POST, enter a URL such as a CORS-friendly echo endpoint, click + Content-Type (which inserts the header Content-Type: application/json), choose the JSON body type, and paste:
{"name": "Ada", "role": "engineer"}
Press Send. The tool builds the request, sends the body, and renders the response: a coloured status badge (green for 2xx, orange for 4xx, red for 5xx), the elapsed milliseconds, a table of every response header, and the body. If the server echoes JSON back, it is reformatted with two-space indentation against a dark background so it is easy to read. The exact request — method, URL, headers, and body — is saved to a local history of your last five requests, which you can click to reload and resend.
Headers and body types
The Headers section lets you add any key/value pair, with one-tap presets for the three most common: Content-Type, Authorization (pre-filled as Bearer so you just paste your token), and Accept. The body editor appears only for methods that carry a payload (POST, PUT, PATCH) and offers three encodings:
- JSON → sends
application/json; - Form URL-encoded → sends
application/x-www-form-urlencoded(e.g.key=value&other=data); - Plain Text → sends
text/plain.
If you have not already set a Content-Type header yourself, the tool adds the matching one automatically based on the body type you chose. A header you set manually always wins.
Common use cases
- Inspecting a webhook payload format. Fire a sample POST at your receiver and confirm it accepts the body shape you intend to send.
- Checking an API quickly without opening a terminal — verify a GET returns the data you expect, or that an auth token is accepted.
- Reading response headers such as rate-limit counters, cache directives, or content type, all laid out in a table.
- Reproducing a request from history to compare two runs after a change.
Tips and common mistakes
- A blank response is usually CORS, not a dead server. If you get an immediate failure on a third-party URL, the server almost certainly received the request but the browser withheld the response. Test against your own CORS-enabled endpoint to confirm your request is correct.
- Real credentials are really sent. Anything you put in an
Authorizationheader or body goes to the destination server over the network. Only paste tokens for endpoints you trust, and avoid production secrets in casual testing. - Some headers cannot be set from a browser. The fetch API forbids "unsafe" headers like
Host,Origin, andUser-Agent; the browser controls those. If a server needs them, use a server-side client. - History is local only. Your last five requests are stored in this browser's
localStorage, not on any server, and you can clear them at any time. They never sync to another device.