API Client — Free Postman Alternative
Test REST APIs directly in your browser. All HTTP methods, authentication, collections, history, and environment variables — no signup, no installation.
TL;DR
This client sends real HTTP requests straight from your browser using the native fetch() API. Because it runs in a browser tab, it obeys the same same-origin policy as any web app — so an API that does not send the right Access-Control-Allow-Origin header will be blocked by the browser, not by us. We deliberately do not proxy your traffic, so your tokens never leave your machine. Use the status-code table and the CORS checklist below to figure out why a request failed.
Why a browser API client is different from Postman or curl
Postman (desktop), Insomnia, and curlare native programs. They open a raw socket to the target server and the browser security model never enters the picture. This tool is a web page, so every request travels through the browser's networking stack and inherits its rules. That gap explains almost every "it works in curl but fails here" report.
The same-origin policy. A script on stringtoolsapp.com may freely call APIs on stringtoolsapp.com. To call any other origin (different scheme, host, or port) the browser requires the server to opt in via CORS headers. Without that opt-in the response is hidden from JavaScript even though the bytes may have arrived.
Preflight requests. For anything beyond a "simple" request, the browser first sends an automatic OPTIONS call asking permission. If your server does not answer that OPTIONS with the right headers, the real request is never sent — you will see two entries in DevTools and a console error, but your handler runs zero times.
Forbidden headers. The browser refuses to let scripts set certain headers — Host, Origin, Referer, Content-Length, Cookie (cross-site), and the User-Agent in some browsers. curl can set all of these. If a request depends on overriding one, it cannot work from any browser tab.
Why we do not offer a CORS proxy
Many online API testers "solve" CORS by routing your request through their own backend, which strips the browser restriction and re-adds permissive headers. That works, but it means every URL, header, request body, and — critically — every Bearer token, Basic credential, and API key you send passes through, and can be logged by, a server you do not control.
We made a different choice. This site is a static export with no backend that could receive your traffic. Requests go directly from your browser to the target API. The trade-off is honest: when CORS blocks a request, we tell you instead of silently tunneling your secrets through a middleman. If you must call a CORS-restricted API, use a native tool (curl, Postman desktop, Insomnia, HTTPie) where the browser rules do not apply.
Authentication types and the headers they produce
The Auth tab generates the correct header or query parameter for you, but it helps to know exactly what goes on the wire. Here is what each scheme sends, and the gotcha that trips people up most often.
| Type | What gets sent | Common gotcha |
|---|---|---|
| Bearer token | Authorization: Bearer <token> | Do not paste the word "Bearer" into the token field — the tool adds it. Doubling it produces Bearer Bearer ... and a 401. |
| Basic auth | Authorization: Basic <base64(user:pass)> | It is base64, not encryption. Over plain http:// the credentials are effectively in cleartext — only use it over HTTPS. |
| API key (header) | A custom header, e.g. X-API-Key: <key> | The header name varies by vendor (X-API-Key, apikey, X-Auth-Token). A custom header also triggers a CORS preflight. |
| API key (query) | ?api_key=<key> appended to the URL | Keys in the URL leak into server logs, browser history, and the Referer header. Prefer the header form when the API allows it. |
| Cookie / session | Cookie header (set by the browser) | Scripts cannot set the Cookie header. Cross-site cookies also need credentials: include plus Access-Control-Allow-Credentials on the server. |
HTTP status code reference
The status code on the response is the fastest way to localize a problem. A code in the 4xx range means your request was wrong; a 5xx means the server failed. These are the codes you will actually meet while testing REST APIs.
| Code | Name | What it means when testing |
|---|---|---|
200 | OK | Success with a body. Standard response for GET and most successful calls. |
201 | Created | A POST created a resource. Look for a Location header pointing at the new item. |
204 | No Content | Success with an empty body — common for DELETE and PUT. An empty response here is correct, not a bug. |
301 / 302 | Moved / Found | A redirect. fetch follows these automatically; watch for an http to https upgrade that drops your Authorization header. |
304 | Not Modified | Your cached copy is still valid (If-None-Match / ETag). No body is returned. |
400 | Bad Request | Malformed body or params. Check your JSON is valid and the Content-Type matches what you sent. |
401 | Unauthorized | No valid credentials. Missing, expired, or malformed token. Despite the name it means "unauthenticated". |
403 | Forbidden | You are authenticated but lack permission for this resource. A scope or role is missing, not the token itself. |
404 | Not Found | Wrong path or the resource does not exist. Often a missing /v1/ prefix or a typo in an ID. |
405 | Method Not Allowed | The endpoint exists but rejects this verb — e.g. you sent POST to a read-only GET route. |
415 | Unsupported Media Type | Your Content-Type is not accepted. Sending form-data where the API expects application/json is the usual cause. |
422 | Unprocessable Entity | Valid JSON but fails validation — a required field is missing or a value is out of range. |
429 | Too Many Requests | Rate limited. Read the Retry-After and X-RateLimit-* headers and back off. |
500 | Internal Server Error | The server crashed handling your request. The bug is on their side — but your payload may have triggered it. |
502 / 503 / 504 | Gateway / Unavailable / Timeout | Infrastructure problem: a bad upstream, an overloaded service, or a slow backend behind a proxy. |
0 / none | No status | The request never completed: a CORS block, a DNS or TLS failure, or a network drop. See the checklist below. |
"Why did my request fail?" — a CORS & network checklist
When the response shows no status code and DevTools logs a red error, the request was stopped before JavaScript could read it. Walk this list top to bottom — the items are ordered by how often they are the real cause.
1. No Access-Control-Allow-Origin on the response.
The most common cause. The API simply does not allow cross-origin browser calls. The fix is on the server (add the header) or use a native tool. There is nothing this page can do from the browser.
2. The preflight OPTIONS request failed.
Adding a custom header (like an API key) or using PUT/PATCH/DELETE forces a preflight. The server must answer OPTIONS with Access-Control-Allow-Methods and Access-Control-Allow-Headers that include what you are sending.
3. Origin not in the allow-list.
The server returns Access-Control-Allow-Origin but set to a specific site (not * and not stringtoolsapp.com). The browser then blocks the response even though the server replied.
4. Credentials mismatch.
If a request includes cookies, the server cannot use Access-Control-Allow-Origin: * — it must echo the exact origin and add Access-Control-Allow-Credentials: true. Missing either one blocks the response.
5. Mixed content (HTTPS page calling HTTP).
This page is served over HTTPS, so the browser blocks a plain http:// target on a public host as insecure mixed content (loopback addresses like localhost are exempt in most browsers — see item 7). Use the https:// endpoint instead.
6. DNS, TLS, or a dead host.
A typo in the hostname, an expired certificate, or a server that is down produces a network error with no status. Try the same URL in a new browser tab to confirm it resolves at all.
7. Localhost during development.
Most browsers (Chrome, Edge, Firefox) treat http://localhost and 127.0.0.1 as secure origins, so calling them from this HTTPS page is not blocked as mixed content — Safari is the exception and does block them. When a localhost call fails in a permissive browser, the usual cause is CORS: your local server still has to send Access-Control-Allow-Origin. If it cannot, run the API over HTTPS or test it with curl or a desktop client.
API testing questions developers actually ask
Why does it work in curl or Postman but fail here with a CORS error?
curl and Postman desktop are native programs that open a direct socket to the server, so the browser's same-origin policy never applies. This tool is a web page, so every request goes through the browser, which enforces CORS. If the API does not send Access-Control-Allow-Origin, the browser blocks the response before your code can read it — even though the server may have answered fine.
What is the difference between 401 and 403?
A 401 Unauthorized means you are not authenticated — your token is missing, expired, or malformed, so fix the credentials. A 403 Forbidden means you are authenticated but lack permission for that specific resource or action; the token is valid but missing a scope or role. Same token, different problem.
Why do you not add a proxy to get around CORS?
A CORS proxy would route every request — including your Bearer tokens, Basic credentials, and API keys — through a server we operate, where it could be logged. This site has no backend by design, so requests go straight from your browser to the API and your secrets never leave your machine. For CORS-restricted APIs, use curl, Postman desktop, Insomnia, or HTTPie, where browser rules do not apply.
Should I put my API key in a header or in the query string?
Prefer a header (such as X-API-Key or Authorization) whenever the API supports it. Keys placed in the query string end up in server access logs, browser history, and the Referer header sent to third parties, which is a common way credentials leak. Use the query form only when the API offers no header option.
What is a preflight (OPTIONS) request and why do I see two requests?
For any non-simple request — a custom header, a JSON body with PUT/PATCH/DELETE, or certain content types — the browser first sends an automatic OPTIONS request to ask the server's permission. If that preflight succeeds, the real request follows, which is why you see two entries in DevTools. If the server does not answer the OPTIONS correctly, the real request is never sent at all.
Are my requests, tokens, and collections sent to your servers?
No. The site is a static export with no backend, so requests go directly from your browser to the target API. Your collections, history, and environment variables live only in your browser's localStorage. Because there is no proxy, we never see your URLs, headers, bodies, or auth tokens. Export your collections as JSON periodically so you do not lose them if you clear browser data.