CORS Tester
The CORS Tester simulates the preflight request a browser makes before a cross-origin call — an OPTIONS request carrying an Origin header and an Access-Control-Request-Method header — against any origin and target URL you choose. It shows the preflight's status code and every Access-Control-Allow-* header the server returned, then translates that into a plain allowed or blocked verdict. It's built for debugging why a fetch() call works from curl but fails in the browser with a CORS error.
How it works
A browser decides whether to allow a cross-origin request by first sending a preflight OPTIONS request — for most non-trivial requests — and inspecting the Access-Control-Allow-Origin, Access-Control-Allow-Methods and related headers in the response before it lets your actual request through. You can't easily reproduce that check from a script in your own page, because the browser applies the exact same CORS restrictions to this tool's own network calls that it applies to everything else. So we run the preflight from our edge proxy instead, which isn't subject to browser CORS enforcement and can make the request and read the raw response freely.
You supply an origin (the site making the request) and a target URL (the API being called), and the proxy sends an OPTIONS request to the target with an Origin header set to your chosen origin and an Access-Control-Request-Method header set to the HTTP method you intend to use. It then reads back the preflight's status code and any Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers and Access-Control-Allow-Credentials headers the target returned, and applies the same matching rules a browser would to decide whether the real request would be allowed or blocked — for example, an Allow-Origin of a different origin with no wildcard means blocked, even if the preflight itself returned 200.
Only the origin and target URL you enter are sent to the proxy for that one check, and neither is stored afterward.
Frequently asked questions
Why does my request work in Postman but fail in the browser with a CORS error?
Postman and curl don't enforce CORS at all — only browsers do, as a security boundary between origins. A request that succeeds outside the browser can still be blocked once it runs inside a page's JavaScript.
What triggers a CORS preflight request?
Any request that isn't a 'simple' request — for example one using methods other than GET/HEAD/POST, custom headers, or a Content-Type other than a few plain-text ones — triggers a preflight OPTIONS request first.
Why is Access-Control-Allow-Origin: * not enough for authenticated requests?
Browsers refuse to combine a wildcard Allow-Origin with credentials like cookies or Authorization headers. If you need credentialed cross-origin requests, the server must echo back the specific requesting origin instead of using a wildcard.
Does a 200 response to the preflight mean the request is allowed?
Not necessarily. The preflight can return 200 while still omitting or misconfiguring the Access-Control-Allow-* headers a browser needs — status code alone doesn't determine the CORS verdict.
Can I test requests that use cookies or Authorization headers?
Yes — set the credentials option when checking, and the tool will verify whether Access-Control-Allow-Credentials is present and whether Allow-Origin is a specific origin rather than a wildcard, both of which are required together.