API Tester
Send a request, read the whole response
Any method, any headers, any body — sent through this site’s own proxy so CORS cannot block it, with status, timing and headers returned in full.
API Tester
Sends requests through this site’s server01 — How to use API Tester
02 — Getting good results
03 — Questions
Because CORS is enforced by the browser itself, not by the page. When a server does not send permissive CORS headers, the browser refuses to let JavaScript read the response — that is the entire purpose of the policy. Bypassing it requires making the request from somewhere that is not a browser, which means a server.
The proxy does not store request bodies or responses. It is rate limited per IP, which requires seeing the address the request came from, and failures are logged without their contents. Treat anything you send as having passed through a third party, because it has.
Responses up to 5 MB, a 15-second timeout, at most 5 redirects, and 30 requests a minute per address. Beyond those the tool reports which limit was hit.
Cookie and Set-Cookie headers are stripped in both directions. A shared proxy that forwarded credentials would let one person’s session travel to somebody else’s chosen destination, which is a hole rather than a feature. Use a bearer token in an Authorization header if the API supports one.
04 — More about API Tester
What CORS actually is, and why it blocks you
Cross-Origin Resource Sharing is a browser mechanism, not a server one. When a page on one origin asks for a resource on another, the browser makes the request but refuses to hand the response to the page unless the server included headers granting permission. The restriction exists because browsers send cookies automatically: without it, any page you visited could read your email by requesting it with your own session attached. The consequence for a developer is that a perfectly working API can be entirely unreachable from a browser-based tool, not because anything is broken but because the API never anticipated being called from one. Command-line clients are unaffected, because they have no ambient credentials to abuse and no same-origin policy to enforce.
Why relaying requests safely is harder than it looks
A service that fetches whatever URL it is given is a server-side request forgery vector, and a naive one is genuinely dangerous. The classic attack is not against a public site at all: cloud providers expose an instance metadata service on a link-local address that returns credentials to anything on the machine that asks. A proxy that will fetch that address hands those credentials to anyone. Blocking the address by string comparison is insufficient, because a hostname can resolve to it, and blocking the resolved address is also insufficient, because an attacker-controlled nameserver can return a public address when checked and a private one microseconds later when connected — the rebinding attack. The proxy behind this tool checks the address at the moment the connection is made rather than when the name is resolved, and applies the same check to every redirect hop.
Reading a response properly
A useful HTTP client shows more than the body. The status code distinguishes a working endpoint returning nothing from a broken one; the headers reveal content type, caching behaviour, rate-limit budgets and which server actually answered; the timing distinguishes a slow API from a slow network. This tool surfaces all of it, and keeps the request side visible too, because a surprising number of API problems turn out to be a header that was not sent or was sent with the wrong name. Binary responses are reported by size and type rather than dumped as base64, since several megabytes of encoded bytes in a text pane helps nobody.
61 more tools
where this came from.
Same shell, same shortcuts, same promise: nothing leaves your browser.