Skip to content
koducathome

API Tester

Test REST APIs from your browser with custom methods, headers, query parameters and bodies. See status, timing, headers and the response body.

How to use this tool

Steps for using the API Tester.

  1. Choose an HTTP method from the colour-coded menu and enter an absolute https:// URL — or click GET sample / POST sample, or Import cURL to paste a command from DevTools or API docs.
  2. Add query parameters in the Params tab — they stay in sync with the URL and are percent-encoded for you. Untick a row to leave it out without deleting it.
  3. Use the Auth tab for a Bearer token, Basic username/password or an API key (as a header or query parameter). Auth values stay in memory only and are never saved.
  4. Add other headers in the Headers tab (with one-click presets). For POST, PUT and PATCH, pick a Body type — JSON (with live validation and Format JSON), form fields or plain text; a matching Content-Type is added automatically.
  5. Press Send or Ctrl/⌘ + Enter. Read the colour-coded status, time and size, then switch between the pretty or raw Body, the Headers table and Details. Press Cancel to abort; requests time out after 30 seconds.
  6. Open the Code tab to copy the request as cURL, fetch, Axios, Python, Go or PHP, and click any entry in History to load an earlier request again.

Example

Copy a POST request as cURL

Request
POST https://jsonplaceholder.typicode.com/posts
Content-Type: application/json
Authorization: Bearer abc123

{"title":"It's here"}
Copy as cURL
curl -X POST 'https://jsonplaceholder.typicode.com/posts' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer abc123' \
  --data-raw '{"title":"It'\''s here"}'

Common use cases

  • Checking that a public or staging endpoint returns the expected status and JSON shape before wiring it into a front-end.
  • Reproducing a bug report by replaying a request with the same headers, query parameters and body.
  • Verifying that a CORS configuration actually lets your web app's origin call the API.
  • Trying a bearer token or API key against a local development server on localhost.
  • Turning a request built here into a cURL command to share with a teammate or paste into a ticket.

How browser-based API testing works (and where CORS comes in)

This tester calls the browser's fetch() directly from your tab. There is no proxy server in between: your request — including any tokens you put in headers — travels straight from your machine to the API, and the response is never seen by us. That keeps secrets out of third-party logs, and it means private hosts such as http://localhost:3000 or a VPN-only staging server work exactly as they would for your own front-end code. Nothing you type is stored, not even in local storage, and analytics only records that a request was sent and whether it succeeded — never the URL, headers or body.

The trade-off is that browser security rules apply. Under the same-origin policy, a page may only read responses from another origin if that server opts in with CORS headers. For anything beyond a simple GET or POST — custom headers like Authorization, a JSON Content-Type, or methods like PUT and DELETE — the browser first sends a preflight OPTIONS request and only continues if the server answers with matching Access-Control-Allow-Origin, Access-Control-Allow-Methods and Access-Control-Allow-Headers. When that fails, fetch() rejects with a generic network error and deliberately hides the reason. Many public APIs allow any origin; most internal APIs only allow their own front-end. Tools like cURL, Postman and server code are not browsers, so CORS does not apply to them — use Copy as cURL or the cURL to Code converter when the browser blocks a request.

Mixed content is the other common blocker: this page is served over HTTPS, so browsers refuse to let it call a plain http:// URL on another host. Loopback addresses such as localhost and 127.0.0.1 are treated as trustworthy and are allowed by current browsers. Some headers are also controlled by the browser and silently dropped from fetch() — Host, Cookie, Origin, Referer, Content-Length and others — so the tool warns you instead of pretending they were sent. Requests are made with credentials: "omit", so your browser cookies for the target site are not attached.

On the response side, the status code is colour-coded by class (2xx success, 3xx redirect, 4xx client error, 5xx server error). Time is measured with performance.now() from the call until the whole body has been read, so it includes DNS, TLS, server time and download. Size is the UTF-8 byte length of the decoded body text; headers are excluded and compressed transfer size is not visible to page scripts. For cross-origin responses the browser only exposes CORS-safelisted headers (such as Content-Type, Cache-Control and Content-Length) unless the server lists more in Access-Control-Expose-Headers, and Set-Cookie is never readable. JSON bodies are detected from the Content-Type (or a body that starts with { or [) and pretty-printed; everything else is shown raw. See the guide to testing a REST API for a step-by-step walkthrough.

Limitations

  • Subject to CORS: servers that do not allow this site's origin cannot be read from the browser. There is intentionally no proxy to work around this.
  • Plain http:// URLs on remote hosts are blocked as mixed content; localhost is allowed.
  • Browser-controlled headers (Host, Cookie, Origin, Referer, Content-Length, Sec-*, Proxy-*) cannot be set.
  • Bodies are sent as JSON, URL-encoded form fields or text — multipart file uploads and binary bodies are not supported. Binary responses are shown as text.
  • History lives in the open tab only (auth values are never included) and is lost on reload — there is no saved collection.
  • Only CORS-exposed response headers are visible, and redirects are followed automatically (the final URL is shown).

Frequently asked questions

Why does my request fail here but work in Postman or cURL?

Almost always CORS. Postman and cURL are not browsers, so they ignore the same-origin policy. In a browser, the API must return Access-Control-Allow-Origin (and for preflighted requests, matching allow-methods and allow-headers). Copy the request as cURL to confirm the endpoint itself works.

Is my API key or token sent anywhere else?

No. Requests go directly from your browser to the URL you enter. There is no proxy, nothing is saved to local storage, and analytics never includes URLs, headers or bodies. The token is, of course, sent to the server you are calling — only use credentials you trust that server with.

Can I test an API running on localhost?

Yes. Browsers treat http://localhost and 127.0.0.1 as secure contexts, so they are not blocked as mixed content. Your local server still needs to send CORS headers that allow this site's origin, and recent versions of Chrome may ask you to allow this site to access your local network first.

Why can't I see all the response headers?

For cross-origin responses, browsers only expose CORS-safelisted headers to JavaScript unless the server names others in Access-Control-Expose-Headers. Set-Cookie is never exposed. Use cURL with -i to see every header, then paste them into the HTTP Header Inspector.

Why is the body editor disabled for GET?

The Fetch standard does not allow a body on GET or HEAD requests, and browsers throw an error if you try. Put data in query parameters instead, or switch to POST, PUT or PATCH.

How do I turn this request into code?

Click Copy as cURL, then paste the command into the cURL to Code converter to get JavaScript fetch, Axios, Python or Go. The cURL to JavaScript guide explains the mapping.