CORS Tester
Send a real cross-origin request from your browser to any URL, with your own method, headers, body and credentials mode, and find out whether CORS allows it. When it fails, follow-up probes tell you whether the cause is the preflight, credentials, a missing Access-Control-Allow-Origin header or the network.
Last updated:
Request analysis
Origin sent by your browser:
Probes
Response
Inspect and fix on the server
Browsers hide CORS headers from scripts. Run this with curl to see exactly what the server returns:
The server must answer with headers like these (adjust to your needs):
How to use the CORS Tester
- Enter the API URL and pick the HTTP method.
- Add headers and a body the way your front end sends them, for example Authorization or Content-Type: application/json.
- Choose the credentials mode: include sends cookies, which needs stricter server headers.
- Check the request analysis to see whether the browser will send a preflight, then click Send Request.
- Read the verdict, then copy the curl command and the required headers to fix the server.
CORS response headers explained
| Header | Sent on | Purpose |
|---|---|---|
Access-Control-Allow-Origin | Every response | The origin allowed to read the response, or * for any origin (not with credentials) |
Access-Control-Allow-Methods | Preflight | Methods allowed for the actual request, such as GET, POST, PUT, DELETE |
Access-Control-Allow-Headers | Preflight | Request headers the page may send, such as authorization, content-type |
Access-Control-Allow-Credentials | Both | true lets requests with cookies or HTTP auth read the response |
Access-Control-Expose-Headers | Actual response | Extra response headers scripts may read, such as x-total-count |
Access-Control-Max-Age | Preflight | Seconds the browser may cache the preflight result (browsers cap it, Chrome at 2 hours) |
Vary: Origin | Every response | Stops caches from serving one origin's CORS answer to another origin |
Common CORS errors and their fixes
- No 'Access-Control-Allow-Origin' header is present: the server does not send CORS headers at all, or only on success responses. Add the header to every response, including 4xx and 5xx errors.
- Response to preflight request doesn't pass access control check: the OPTIONS request returns 401, 404 or 405. Handle OPTIONS before authentication and routing and return 204 with the Allow headers.
- Request header field authorization is not allowed: add the header name to
Access-Control-Allow-Headers. - The value of the header must not be the wildcard '*' when credentials mode is 'include': echo the request's Origin (from an allow list) and add
Access-Control-Allow-Credentials: true. - Redirect is not allowed for a preflight request: the URL redirects (for example http to https or a missing trailing slash). Call the final URL directly.
Example for nginx: add_header Access-Control-Allow-Origin $http_origin always; combined with an allow-list map, and if ($request_method = OPTIONS) { return 204; }. In Express, the cors middleware with { origin: ['https://app.example.com'], credentials: true } handles both preflight and actual responses.
Frequently asked questions
What is CORS?
Cross-Origin Resource Sharing is the browser rule that decides whether JavaScript on one origin (scheme, host and port) may read a response from another origin. The server opts in by sending headers such as Access-Control-Allow-Origin. Without them the browser still sends many requests but hides the response from the page.
What is a preflight request?
Before a non-simple request, the browser sends an OPTIONS request with Access-Control-Request-Method and Access-Control-Request-Headers to ask permission. A request is simple only if it uses GET, HEAD or POST, has only safelisted headers such as Accept, and a Content-Type of text/plain, multipart/form-data or application/x-www-form-urlencoded. Sending JSON or an Authorization header always triggers a preflight.
Why can't the tool show the Access-Control-Allow-Origin header?
Browsers do not let scripts read most response headers, including the CORS headers, and on a CORS failure they give no detail at all. That is why the tool runs extra probes to narrow down the cause and gives you a curl command that shows the raw headers the server returns.
Why does my request work in Postman or curl but not in the browser?
CORS is enforced only by browsers. Postman, curl and server-side code ignore it, so a missing Access-Control-Allow-Origin header only shows up in front-end code. Fix it on the API server or route the call through your own back end.
Can I use Access-Control-Allow-Origin: * with cookies?
No. When the request uses credentials (cookies or HTTP authentication), the server must echo the exact origin and send Access-Control-Allow-Credentials: true. A wildcard origin is rejected by the browser in that case. Also add Vary: Origin so caches keep responses per origin.
Which origin does this test use?
The request is sent from this page, so the Origin header is freetoolcabin.com. If your API only allows your own site's origin, the test will show blocked even though your site works. Use the curl command with your real origin to confirm.
Is my request sent through FreeToolCabin?
No. The request goes straight from your browser to the URL you enter. There is no proxy, and nothing is stored. Avoid pasting production secrets into headers on shared computers.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.