Network/HTTP
CORS Checker / Explainer
Explain step by step whether the browser will allow a cross-origin request — simple/preflight classification, Access-Control-* response header checks, and a verdict.
One per line, "Name" or "Name: value" — the value does not affect the classification.
Grab these from the Network tab in DevTools (the response itself or the OPTIONS preflight) or curl -I.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Article about this tool: CORS: why the browser blocks "normal-looking" requests to another domain
Frequently asked questions
Why does a request fail with a CORS error even though the server responded successfully?
CORS is enforced by the browser, not the server — if the response is missing an Access-Control-Allow-Origin header matching the requesting origin, the browser blocks JavaScript from reading the response, even though the request itself completed.
What's the difference between a simple request and a preflighted request?
Simple requests (basic GET/POST with standard headers) go straight through, while requests with custom headers, other methods, or certain content types trigger a preflight OPTIONS request first to check permission before the real request is sent.
Does checking CORS headers here send my data to a server?
The tool inspects headers you provide or fetch directly from your browser — no intermediary server stores your request data.
Does CORS protect an API from malicious requests?
No. CORS only restricts what a browser will let page JavaScript read — an attacker can send the same request directly via curl or a script, bypassing the browser and any CORS restrictions entirely.
Why doesn't Access-Control-Allow-Origin: * work together with credentials: include?
The spec forbids this combination on purpose — letting any site read responses along with a user's cookies or authorization would be a serious security hole, so the server must return a specific Origin instead of "*" in that case.