API Tester

A lightweight HTTP client for testing endpoints: methods, query params, headers, and body, with pretty-printed responses and request history. Requests go straight to the target, never through a proxy.

How to use the API Tester

  1. Choose an HTTP method (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) and enter the request URL.
  2. Use the Params, Headers, and Body tabs to configure the request — each key/value row has a checkbox to enable/disable it without deleting it.
  3. Click Send (or press Enter in the URL bar) to fire the request.
  4. Review the response status, timing, and size in the status bar, and expand "Response Headers" to inspect them.
  5. JSON responses are automatically pretty-printed; click Copy to grab the response body.
  6. Open History to revisit and re-run a recent request.

Requests run directly from your browser, so they're subject to CORS — if a request fails with "Failed to fetch," the target server likely needs to allow cross-origin requests, not that the endpoint is down. Click Cancel (in place of Send) to abort an in-flight request.

About the API Tester

Before you write the client code, you want to see what the endpoint actually returns. Not what the documentation claims — the real status code, the real headers, the real body shape.

This is a small HTTP client that runs in the browser tab. Set a method and URL, add query parameters, headers, and a body, send it, and inspect the response with JSON pretty-printed automatically. Requests go directly from your browser to the target, not through any intermediary.

When you'd use it

  • Checking the shape of a response before writing the types for it.
  • Reproducing a failing request with one header changed to isolate the cause.
  • Verifying that an endpoint is up and what it returns for an unauthenticated request.
  • Testing a webhook receiver by sending it a representative payload.
  • Confirming which CORS headers a server actually sends.

CORS: read this before you conclude the endpoint is broken

Requests are made with the browser fetch API, which means they are subject to the same-origin policy. If the server does not return an Access-Control-Allow-Origin header covering this page's origin, the browser blocks your JavaScript from reading the response — even though the request was sent and the server answered normally.

The symptom is a generic "Failed to fetch" with no status code, because the browser withholds the response entirely. It is easy to misread as the endpoint being down. It is not: it is the browser refusing to hand your script a response the server did not authorise it to read.

When that happens, the endpoint is fine and the browser is the constraint. A command-line client such as curl has no same-origin policy and will show you the response. The cURL converter in the utility tools will turn a working curl command into code for your language once you have confirmed the shape.

Headers the browser will not let you set

A set of headers is controlled by the browser and cannot be overridden from JavaScript, because servers rely on them being trustworthy. Setting them here has no effect and produces no error, which is confusing the first time.

  • Host, Origin, and Referer — set by the browser to reflect where the request genuinely came from.
  • Connection, Content-Length, and Transfer-Encoding — managed by the HTTP stack.
  • User-Agent — fixed to the browser's own in most cases.
  • Cookie — governed by the browser's cookie store and the request's credentials mode, not by a header you supply.

Preflight requests

For anything beyond a simple GET or POST with a basic content type, the browser first sends an OPTIONS request asking the server what is permitted. Adding an Authorization header or sending application/json triggers this.

If the preflight fails, your actual request is never sent. In the network panel you will see an OPTIONS request and no POST, which tells you the problem is the server's CORS configuration rather than your request body or your credentials.

Credentials do not leave your browser

There is no proxy in this tool. Your browser opens the connection to the target host directly, so an API key in a header goes to that host and nowhere else. That is a meaningfully different trust model from hosted API clients, which route requests through their own infrastructure and therefore see everything you send.

Request history is stored in your browser's local storage so you can re-run a request after a refresh. That includes any headers you set, so clear the history on a shared machine.

Frequently asked questions

Why does every request fail with "Failed to fetch"?
Almost always CORS. The request was sent and answered; the browser blocked your script from reading the reply. It can also be a mixed-content block — an https page cannot make http requests — or a genuinely unreachable host.
Can I call an API on localhost?
Yes, if the local server sends CORS headers permitting this origin. Many development servers allow all origins, in which case it works immediately.
Are my requests logged anywhere?
Not by this site. Requests go straight from your browser to the target you name, and history is kept in your browser's local storage.
Can I upload a file as the body?
The body editor is text — JSON, form-encoded, XML, or plain text. Multipart file upload is not supported.
Is there a request timeout?
Requests run until the browser gives up, and Cancel replaces Send while one is in flight so you can abort it.

Related tools

JSON Editor Type Generator