API Request Tester — Send HTTP Requests From Your Browser
Compose and send GET, POST, PUT, PATCH and DELETE requests with custom headers and a JSON body, then inspect the status, timing and response.
⚠️ This tool sends real requests
Requests go from your browser directly to the URL you enter — there is no proxy of ours in between, and nothing is logged or stored on our side. The destination server will see your IP and anything you put in the headers or body, so treat credentials exactly as you would in a terminal.
Input
GET https://api.example.com/v1/users · Accept: application/json Output
200 OK · 142 ms
[
{ "id": 1, "name": "Ada" }
] JSON responses are pretty-printed automatically; anything else is shown raw. The response depends on the live endpoint you call, so this shows the shape rather than a fixed result.
Common Use Cases
Checking your own API from a browser
Hit an endpoint you control and see the status, timing and parsed JSON without wiring up a client or writing a throwaway fetch script.
Confirming a CORS configuration
The clearest way to prove your Access-Control-Allow-Origin setup actually works is a real cross-origin browser request, which is exactly what this makes.
Reproducing a failing request
Rebuild a request header by header to find which one breaks it — a missing Content-Type, a malformed token, an extra field the endpoint rejects.
Reading a response you cannot see in the network tab
Inspect status, timing and body for an endpoint in isolation, without the noise of a full application making dozens of parallel calls.
Frequently Asked Questions
- Why does my request fail with a CORS or "Failed to fetch" error?
- Because a browser will not let one origin read another origin's response unless the server allows it. The API has to send an Access-Control-Allow-Origin header naming this site (or "*"), and for anything beyond a simple GET the browser first sends an OPTIONS preflight the server must also answer. Most public APIs do neither, so the request is blocked before a response is ever read. This is not the endpoint being down: the identical request from curl or Postman's desktop app succeeds, because neither is a browser enforcing the same-origin policy.
- Does my API key or token go through your servers?
- No. The request is issued by your own browser with fetch(), straight to the URL you type. There is no proxy, logging or storage on our side, and the history list lives in the page and disappears when you close the tab. The destination server does see your IP address and whatever you put in the headers or body, exactly as it would from any other client.
- Why does the Headers tab show fewer headers than the server sent?
- Browsers only expose a small CORS-safelisted set — Content-Type, Cache-Control, Expires, Last-Modified, Pragma and Content-Language — unless the server adds Access-Control-Expose-Headers listing the others. So values like X-RateLimit-Remaining or a custom request-id are genuinely present on the wire but unreadable from JavaScript. Use curl or your server logs when you need to see everything.
- Can I send a body with a GET request?
- No, and the tool disables it. The fetch() specification forbids a body on GET and HEAD, and will throw if you try. This is not an arbitrary restriction: HTTP semantics give a GET body no defined meaning, so proxies and caches are free to drop it. If you need to send data with a read, put it in the query string, or use POST if the payload is too large or sensitive for a URL.
- How is this different from the cURL Command Builder?
- This page actually sends the request and shows you the response; the cURL Command Builder produces a shell command for you to run elsewhere. The builder has no CORS limitation because curl is not a browser, so the two complement each other: compose here when the API allows browser calls, and build a curl command for the ones that do not.
- Where does my request data actually go?
- Straight from your browser to the URL you enter, and nowhere else. There is no proxy or backend of ours in the path: the request is made by your own browser, so the destination sees your IP and anything you put in the headers or body. Nothing is logged or stored on our side, and the page keeps no history after you close the tab. Treat any credential you paste here exactly as you would in a terminal — it is going to a real server, just not to us.