A CORS tester that tells you why a request is blocked
When a web page calls an API on another origin, the browser enforces CORS (Cross-Origin Resource Sharing): it may first send an OPTIONS preflight, and it only lets the page read the answer if the API’s Access-Control-* headers allow the page’s origin. The browser’s own error — “blocked by CORS policy” — rarely says what to fix. This CORS tester sends the same preflight and request with the origin, method and headers you choose, shows every CORS header that comes back, and explains the verdict step by step.
The test runs from a server, so you can check any origin — production, staging or http://localhost:3000 — without deploying anything. Optionally, the page can also send a real fetch from your browser to confirm what the browser itself allows for this page’s origin.
How to use the CORS Tester
- Paste the endpoint into API URL.
- Set Origin to test to the site whose pages call the API. It starts as this page’s origin.
- Choose the Method and list the Request headers your code sets, such as
Content-Type, Authorization. - Tick With credentials if the request sends cookies or HTTP authentication (
credentials: "include"). - Press Test CORS. Read the verdict, the reasons, and the headers of the preflight and the response.
CORS Tester features
Real preflight, real headers
An OPTIONS request with Origin, Access-Control-Request-Method and Access-Control-Request-Headers — lower-cased and sorted as browsers send them — then a GET with the same Origin.
Browser rules applied
Safe-listed methods and headers, exact origin matching, one value only, the wildcard and credentials rules, Authorization never covered by *, a 2xx preflight and no redirected preflight.
Redirects handled like a browser
Every redirect of the real request must also allow the origin, and after a cross-origin redirect the browser sends Origin: null.
Security hints
Warns about a specific origin without Vary: Origin, allowing the null origin, and echoing origins with credentials.
Optional in-browser check
A GET or HEAD from this page, without cookies, shows what your browser itself allows. It never sends POST, PUT, PATCH or DELETE.
Typical CORS errors and their fixes
| Browser message (Chrome) | Cause | Fix on the API |
|---|---|---|
| No “Access-Control-Allow-Origin” header is present | The response does not allow any origin | Return Access-Control-Allow-Origin with the caller’s origin (or * for public data) |
| Response to preflight request doesn’t pass access control check | OPTIONS got 401, 404 or 405, or lacked the headers | Answer OPTIONS with 204 before authentication runs |
| Wildcard “*” when the credentials mode is “include” | * used with cookies | Echo the exact origin from an allow-list and add Allow-Credentials: true |
| Request header field authorization is not allowed | Header missing from Allow-Headers | List it by name in Access-Control-Allow-Headers |
| Redirect is not allowed for a preflight request | OPTIONS was redirected (often http → https or a missing slash) | Call the final URL directly |
Worked example: api.github.com
Testing https://api.github.com/zen from https://app.example.org with GET and the headers Content-Type, Authorization needs a preflight, because both headers are outside the safe list. The preflight answers 204 with Access-Control-Allow-Origin: * and an Allow-Headers list that names Authorization and Content-Type, so the verdict is Allowed; the Max-Age of 86,400 seconds is cut to two hours by Chrome.
Tick With credentials and the same API is Blocked: a wildcard origin is never accepted with cookies, and there is no Access-Control-Allow-Credentials: true. That is deliberate — the API uses tokens, not cookies.
What this test cannot see
The server sends the preflight and a GET from Cloudflare’s network; the real request is always tested with GET, so it can never change data on your API. Some APIs answer differently to logged-in users, other methods, or particular countries. Only public http/https addresses on ports 80 and 443 are tested, and each network may run 60 tests every 10 minutes. CORS also protects only browsers: servers, curl and mobile apps ignore it, so it is not an access-control system — use authentication for that. To inspect every header an endpoint returns, try the HTTP Header Checker; to read a JWT you send in Authorization, the JWT Decoder.
CORS Tester FAQ
How do I test CORS on my API?
Enter the API URL, the origin of the site that calls it, the method and the headers your code sends, then press Test CORS. The CORS tester shows whether a browser would allow the call and, if not, which header is missing or wrong.
Why does Postman work when the browser says CORS error?
CORS is enforced only by browsers. Postman, curl and servers send the request and read the answer whatever the headers say, so an API can work there and still be blocked for a web page.
Can I use Access-Control-Allow-Origin: * with cookies?
No. With credentials the browser requires the exact origin and Access-Control-Allow-Credentials: true. Keep an allow-list on the server and echo the matching origin, plus Vary: Origin.
Why is a preflight sent for my GET request?
Because of a header outside the safe list — usually Authorization, a custom X- header, or Content-Type: application/json. A preflight is also sent for PUT, PATCH and DELETE.
Can I test localhost or an intranet API?
The API must be public, because the test runs on a server. The origin can be anything, including http://localhost:3000, since it is only sent as a header value.
Does the test change data on my API?
No. The server sends only OPTIONS and GET, and the optional browser test only GET or HEAD — never POST, PUT, PATCH or DELETE.