Check whether an API allows cross-origin requests. Simulate any Origin, method, and headers, run the preflight, and read every Access-Control-Allow-* header the server returns — even when a browser would block the response.
Send a request from any origin and see exactly which Access-Control-Allow-* headers an API returns — and whether a browser would allow the response.
The website that would call the API, e.g. https://app.example.com.
Comma-separated header names your app sends. Non-simple ones (Authorization, Content-Type) trigger a preflight.
Cookies or Authorization sent with the request (fetch credentials: 'include').
The request runs from our server so the headers can be read even when a browser would block them. Nothing is stored.
The CORS Tester checks whether an API allows cross-origin requests from a specific website, so you can see exactly why a browser fetch is blocked — or confirm it will work before you ship. Enter the API URL and the Origin that would call it, pick the method and any custom request headers, and the tool sends a real request from our server — plus a preflight OPTIONS when the request needs one — then reads back every Access-Control-Allow-* header the API returns. Because the check runs server-side, those headers are visible even when a browser hides them behind a CORS error, and you can simulate any origin instead of only the site you happen to be browsing from. When you want to inspect the same call in more detail, rebuild it from its parsed cURL command.
When the console reads "has been blocked by CORS policy", paste the failing URL and your site's origin here to see whether the server sends Access-Control-Allow-Origin at all, and whether it matches. The verdict tells you the fix belongs on the server, not in your JavaScript.
Before pointing a production frontend at a new endpoint, confirm the origin, method, and headers you plan to use are actually allowed. Catching a missing Allow-Headers entry now is far cheaper than a broken release later.
Cookie- or token-based APIs need Access-Control-Allow-Credentials: true with an exact origin echo — never a wildcard. Turn on credentials to see whether the combination is valid, since browsers silently reject the wildcard-plus-credentials pattern.
Non-simple requests trigger an OPTIONS preflight first. Add the method and headers your app uses and the tester runs that preflight, so you can see whether the browser would ever send the real request.
Not sure whether a public API can be called from the browser at all? Test it from a neutral origin to read its CORS posture — wide-open wildcard, a specific allowlist, or no CORS headers, which means it is server-to-server only.
Staging often allows localhost while production locks down to one origin. Run the same URL against each environment's origin to spot exactly where an allowlist entry was missed.
Access-Control-Allow-Origin: * opens an API to every site but forbids credentials; echoing one exact origin is required the moment cookies or tokens are involved. Choose based on whether the endpoint serves public data or user-specific data.
Browsers reject the combination of * and Access-Control-Allow-Credentials: true. For a credentialed API the server must read the request's Origin header and echo it back verbatim in the response.
If the server reflects whatever origin asked, a shared cache can store one origin's response and hand it to another. Vary: Origin keeps those cached responses separate and is easy to forget behind a CDN.
Access-Control-Allow-Headers: * matches most custom headers but explicitly excludes Authorization. It has to be named in the list, or the preflight for an authenticated request fails even though the wildcard looks permissive.
Command-line tools and API clients do not enforce CORS — it is a browser-only rule. A call that succeeds in a terminal can still be blocked on the page, which is exactly the situation this tester reproduces without a browser.
Some servers answer OPTIONS with 401, 404, or a redirect. Even with correct headers, a non-2xx preflight makes the browser abort before the real request, so check the preflight status, not only the header values.
Reproduce the request, confirm what the server actually allows, then check the pieces that ride along with a cross-origin call — auth tokens and cookies.
Test the CORS headers here
Curl Parser
JWT Debugger
Cookie Parser
A CORS error appears when JavaScript in the browser tries to read a response from a different origin — a different scheme, host, or port — and the server did not return an Access-Control-Allow-Origin header that permits the calling site. The browser still makes the request but hides the response from the page as a security measure. It is a browser-enforced rule, not a network outage or a bug in your code.
The wildcard * tells browsers that any website may read the response. It suits public, non-authenticated data, but it cannot be combined with credentials: if the request carries cookies or an Authorization header, the browser requires the server to echo one specific origin instead of the wildcard.
CORS is enforced only by browsers. Command-line tools and API clients send the request and show the response without applying the same-origin policy, so they never surface a CORS error. This tester recreates the browser's checks server-side, so you can reproduce and diagnose the block without opening a browser.
CORS is fixed on the server that hosts the API, not in your frontend code. The server has to return an Access-Control-Allow-Origin header that matches your site, plus Access-Control-Allow-Methods and Access-Control-Allow-Headers for non-simple requests. The Fix it tab generates the exact configuration for Express, Nginx, Apache, Next.js, and Cloudflare Workers.
For requests that are not simple — anything using PUT, PATCH, or DELETE, a JSON content type, or a custom header such as Authorization — the browser first sends an OPTIONS request called a preflight. The server's response to that OPTIONS decides whether the real request is allowed to proceed at all.
Only when the request includes cookies or an Authorization header sent with credentials: 'include'. In that case the server must return Access-Control-Allow-Credentials: true and echo the exact origin; a wildcard origin is rejected by the browser whenever credentials are present.
CORS relaxes the browser's same-origin policy in a controlled way — it decides what another site's JavaScript is allowed to read. It does not authenticate requests or shield the server itself, since anyone can still call the API directly with a script or curl. Treat it as browser read-permission, not access control.
The tool sends the request you configure from our server to the URL you enter, purely to read the response headers, and nothing is stored. It does not forward your cookies, and it never sends write methods to your endpoint — a safe GET reads the headers while the preflight reports what the real method would do.
To avoid changing anything on your server, the tool never sends a write method to your endpoint. It sends the preflight OPTIONS with your real method in Access-Control-Request-Method — which is what actually decides whether the browser would allow DELETE — and uses a harmless GET to read the response's origin headers.
A warning usually means the origin is permitted but the setup is fragile. Most often the server echoes a specific origin without adding Vary: Origin, so a shared cache or CDN could serve one site's response to another. It works today but can break intermittently, which is worth fixing before it does.