Skip to content
ToolBoxGenie

API Tester

Developer Tools · Added 8 August 2026

Build an HTTP request, send it, and read the response — status code, timing, headers and a pretty-printed body. Requests go straight from your browser to the API you name, never through this site, and you can copy any request out as a cURL command.

Appended to the URL as a query string when the request is sent.

How to use the api tester

  1. 1Pick a method and paste the request URL. If the URL already has a query string, use the link below it to split the parameters into the table.
  2. 2Add query parameters and headers in the tabs. Untick a row to disable it without deleting it.
  3. 3Set bearer or basic authentication under Auth, and a JSON, form or raw body under Body — the Content-Type header is added for you unless you set your own.
  4. 4Press Send. The response appears underneath with the status, elapsed time, size, readable headers and body.
  5. 5Use Copy as cURL to reproduce the exact request in a terminal or a CI script.

Examples

A simple GET

Input
GET https://jsonplaceholder.typicode.com/todos/1
Result
200 OK · ~120 ms · pretty-printed JSON with four fields

This test API sends permissive CORS headers, which is why it works from a browser.

A POST with a JSON body

Input
POST https://jsonplaceholder.typicode.com/posts with body {"title":"Hello","userId":1}
Result
201 Created · the created record echoed back with an assigned id

A request that CORS blocks

Input
GET https://api.github.com/user with a bearer token
Result
Blocked before a response can be read — the browser refuses because the API does not allow this origin

The request may well have reached the server; the browser simply will not hand you the response.

About the api tester

What a browser can and cannot do

The same-origin policy is the foundation of web security: a page at one origin must not be able to read data from another. Cross-Origin Resource Sharing is the mechanism that lets a server opt out of that restriction for specific origins, by returning an Access-Control-Allow-Origin header. Without it, the browser will happily send your request and then refuse to let the page see the answer.

This matters more than it first appears. A failed request here does not mean the API is down, or that your token is wrong, or that your JSON is malformed. It usually means the response arrived and the browser discarded it. That is why the error message on this page lists the alternatives rather than simply saying the request failed.

For requests that are not simple — anything with a custom header, or a JSON content type, or a method beyond GET, POST and HEAD — the browser first sends an OPTIONS preflight asking permission. If the preflight is rejected, the real request is never sent at all.

Reading a response properly

The status code is the first thing to check and the most commonly misread. A 200 with an error message in the body is a badly designed API, not a success. A 401 means the credentials were missing or invalid; a 403 means they were understood and refused, which is a different bug. A 404 on a POST often means the route does not exist rather than the record.

The Content-Type header decides how the body should be interpreted, and this tool pretty-prints accordingly — JSON gets indented, XML and HTML get a light indent, everything else is shown as sent. If a response looks like JSON but will not format, it is not valid JSON, and the raw view will show you why.

Elapsed time is worth watching across repeated calls. A first request that is dramatically slower than the second usually means a cold start, a DNS lookup or a TLS handshake rather than slow application code.

Moving a request out of the browser

Copy as cURL produces the exact request — method, final URL with parameters merged, every enabled header including the Authorization header, and the body. That command can be pasted into a terminal, a CI job or a bug report, and it is not subject to CORS at all.

It is also the honest way to share a reproduction. A description of what you clicked is ambiguous; a cURL command is not. Just remember that the command contains your credentials in plain text, so strip the Authorization header before pasting it into an issue tracker.

Frequently asked questions

Why do some requests fail when the same URL works in Postman?
Because Postman is a desktop application and this is a web page. A page can only read a cross-origin response if the server sends an Access-Control-Allow-Origin header permitting it. Postman is not a browser, so that rule never applies to it. When a request fails here with a network error but works in Postman or curl, CORS is almost always the reason.
Can you not just proxy the request through your server?
We could, and deliberately do not. A public proxy that forwards any URL is an open relay: it can be pointed at internal hostnames, at localhost, or at cloud metadata endpoints that hand out credentials, and every request would pass through our infrastructure in readable form. Keeping the request in your browser means your tokens and payloads never touch a machine of ours.
How do I test an API that blocks my origin?
Three options. Enable CORS on the API for your development origin, which is the right fix if you own it. Run your own instance of the API locally with permissive headers while developing. Or use the Copy as cURL button and run the request from a terminal, where CORS does not exist.
Why can I only see a few response headers?
A cross-origin response exposes just seven safelisted headers by default: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified and Pragma. Anything else — a rate-limit header, a request id, a custom header — is visible only if the server names it in Access-Control-Expose-Headers.
Are my tokens and passwords stored anywhere?
No. Auth credentials live in the form for as long as the tab is open and are sent only to the URL you entered. The request history is kept in memory and never written to local storage, precisely because saved requests would mean saved tokens sitting on your disk.
Why can I not set the Host, Referer or Cookie header?
Browsers reserve a list of forbidden header names that only they may set, because those headers carry security meaning the page must not be able to forge. Requests here also send credentials: omit, so cookies are never attached to a third-party API by accident.
Is the timing figure the same as a server response time?
No. It measures the full round trip from your browser — DNS, TLS negotiation, the CORS preflight if one is needed, the request, and reading the body. Server-side processing is a portion of that. Compare figures across runs rather than treating any single number as the API's latency.

Related tools