API Tester: Real Requests, Real Responses
Unlike a code generator that just shows you what a request would look like, this tool actually sends it — directly from your browser via fetch() — and shows you the real status code, response headers, and body that came back. The tradeoff is that it's bound by the same-origin/CORS restrictions every browser enforces, which a desktop HTTP client wouldn't hit.
A network error almost always means the target server's CORS policy doesn't allow requests from this page's origin — it isn't a bug in the request itself.
Understanding CORS Failures
When your browser makes a cross-origin fetch() request, the target server must respond with an Access-Control-Allow-Origin header naming (or wildcarding) your origin, or the browser blocks JavaScript from reading the response — even if the server processed the request successfully server-side. This is a browser security feature, not a flaw in this tool or necessarily in the target API.
What This Tool Is Good For
Testing public APIs designed for browser consumption, hitting a local development server you control (which you can configure to allow your origin), or quickly checking response shape/headers/timing for an endpoint that does support CORS — all without installing a separate HTTP client application.
Automatic JSON Formatting
If the response body parses as valid JSON, it's automatically pretty-printed for readability; non-JSON responses (plain text, HTML, XML) are shown exactly as received.
Practical Examples
Testing a Public API Endpoint
Checking a CORS-friendly test API.
- 1.Method: GET, URL: a public JSON test endpoint
- 2.Click Send
- 3.Inspect the real status, headers, and formatted body
What's Shown
- Real HTTP status code and status text
- All response headers
- Response body, auto-formatted if JSON
- Round-trip time in milliseconds
Good Use Cases
- Quickly testing a CORS-enabled public API from the browser
- Checking response headers/timing without a separate app
- Testing a local development server's endpoints
- Verifying a request works before wiring it into application code
Frequently Asked Questions
Why do some requests fail with a network error?
This is almost always CORS (Cross-Origin Resource Sharing) — browsers block JavaScript from reading responses from a different origin unless the server explicitly opts in with an Access-Control-Allow-Origin header. Most production APIs are designed to be called from a trusted backend, not directly from arbitrary browser pages, so they don't send this header.
What APIs will actually work with this tool?
APIs specifically designed to allow browser-based cross-origin requests (public test APIs like jsonplaceholder.typicode.com, many public REST APIs with permissive CORS policies), or a server running locally that you've configured to allow your origin. Most authenticated production APIs intended for backend-to-backend use will block the request.
Is this the same as a full HTTP client like Postman or Insomnia?
Not quite — this tool runs entirely inside your browser's own fetch() implementation, which is subject to CORS and other browser security restrictions that don't apply to standalone desktop HTTP clients (which make requests outside the browser sandbox entirely).
How accurate is the response time shown?
It measures wall-clock time from just before the fetch() call to when the response body finishes being read, using the browser's high-resolution performance.now() — a reasonably accurate measure of round-trip time as experienced by your browser, though it includes response body download time, not just server processing time.
Is my request data sent anywhere besides the target API?
No — the request goes directly from your browser to the URL you specify; this tool doesn't proxy or log anything.