CORS Tester
About this tool
How CORS works
Browsers enforce the Same-Origin Policy by default, which prevents JavaScript running on one origin from reading responses from a different origin. CORS provides a controlled way to relax this restriction. When a script on https://app.example.com makes a fetch request to https://api.example.com, the browser automatically includes an Origin: https://app.example.com header. The server at api.example.com inspects this header and decides whether to allow the request. If the origin is permitted, the server responds with Access-Control-Allow-Origin: https://app.example.com (or * for public APIs). The browser compares the Origin it sent with the value returned in Access-Control-Allow-Origin. If they match, the browser allows the script to read the response body and headers. If they do not match, or if the header is absent, the browser blocks the response entirely and reports a CORS error in the console. The actual HTTP response still arrives at the browser, but the browser refuses to expose it to the calling script.
Preflight requests explained
Before sending certain cross-origin requests, the browser first dispatches an OPTIONS request called a preflight to ask the server for permission. Preflight is triggered when the request uses a non-simple method (PUT, DELETE, PATCH), includes custom headers such as Authorization or X-Request-ID, or sets Content-Type to something other than the three form-safe values. The preflight OPTIONS request contains Access-Control-Request-Method indicating the intended HTTP method and Access-Control-Request-Headers listing any custom headers. The server must respond with Access-Control-Allow-Methods enumerating which methods are accepted, Access-Control-Allow-Headers listing which headers are permitted, and Access-Control-Allow-Origin matching the requesting origin. If any of these checks fail, the browser never sends the actual request. To reduce overhead, the server can include Access-Control-Max-Age with a value in seconds, telling the browser to cache the preflight result and skip the OPTIONS request for subsequent calls within that window.
Common CORS errors and fixes
The most frequent CORS misconfiguration is a missing Access-Control-Allow-Origin header, which happens when the server has no CORS middleware configured at all. The fix is to add CORS headers in your server framework or reverse proxy. The second common error is using a wildcard (*) for Access-Control-Allow-Origin while also setting Access-Control-Allow-Credentials: true. The CORS specification explicitly forbids this combination because it would allow any website to make authenticated requests. The solution is to dynamically return the specific requesting origin instead of the wildcard. Third, custom headers like Authorization or X-API-Key require the server to include them in Access-Control-Allow-Headers; omitting this causes preflight failures. Fourth, if your frontend code needs to read non-standard response headers such as X-Request-ID or X-RateLimit-Remaining, the server must list them in Access-Control-Expose-Headers. Finally, mixed-scheme requests (HTTP origin to HTTPS endpoint or vice versa) always fail because different schemes constitute different origins. Use the JWT Debugger to inspect and validate authentication tokens when debugging API access issues alongside CORS.
Frequently Asked Questions
What is CORS?
Cross-Origin Resource Sharing (CORS) is a security mechanism implemented by web browsers that governs how resources on one origin (defined by the combination of scheme, host, and port) can be requested from a different origin. Without CORS, browsers enforce the Same-Origin Policy, which blocks all cross-origin HTTP requests initiated by client-side scripts. CORS relaxes this restriction through a set of HTTP response headers that the server sends to indicate which origins, methods, and headers are permitted. When a browser makes a cross-origin fetch or XMLHttpRequest, it includes an Origin header identifying the requesting page. The server inspects this header and responds with Access-Control-Allow-Origin set to the allowed origin or a wildcard (*). If the returned origin matches the requesting origin, the browser permits the response to be read by the script. Otherwise, the browser blocks the response and logs a CORS error in the developer console. This header-based negotiation happens transparently and does not require changes to the request itself.
What is a preflight request?
A preflight request is an automatic OPTIONS request that the browser sends before the actual cross-origin request to verify that the server will accept it. Preflight is triggered whenever the request uses a method other than GET, HEAD, or POST (such as PUT, DELETE, or PATCH), includes custom headers not on the CORS safelist (like Authorization, X-Custom-Header, or Content-Type with a value other than application/x-www-form-urlencoded, multipart/form-data, or text/plain), or sends credentials to a cross-origin endpoint. The preflight OPTIONS request includes Access-Control-Request-Method and Access-Control-Request-Headers to describe the intended request. The server must respond with Access-Control-Allow-Methods listing the permitted methods, Access-Control-Allow-Headers listing the permitted headers, and Access-Control-Allow-Origin matching the requesting origin. The server can also include Access-Control-Max-Age to tell the browser how many seconds to cache the preflight response, reducing latency on subsequent requests to the same endpoint.
Why does my CORS request fail?
CORS failures are among the most common issues in frontend development and can stem from several distinct server configuration problems. The most frequent cause is a missing Access-Control-Allow-Origin header entirely, meaning the server has no CORS configuration at all. The second most common issue is the server returning a wildcard (*) for Access-Control-Allow-Origin while the request includes credentials (cookies or Authorization headers), which browsers explicitly forbid. Other causes include the server not listing the required HTTP method in Access-Control-Allow-Methods, custom request headers not being included in Access-Control-Allow-Headers, and the client attempting to read response headers that the server has not exposed via Access-Control-Expose-Headers. HTTPS-to-HTTP origin mismatches also trigger failures because the browser treats different schemes as different origins. Finally, some servers handle the preflight OPTIONS request incorrectly by returning a non-2xx status code or omitting the required CORS headers from the OPTIONS response while including them on the actual response.
Is it safe to use this tool?
Yes, this tool is designed with security in mind. When you submit a test, the CORS request is sent from our server infrastructure rather than from your browser. This means that no cookies, session tokens, authentication headers, or any other credentials stored in your browser are included in the test request. The server acts as a neutral proxy, sending a clean HTTP request with only the Origin header and any custom headers you explicitly configure in the form. Your browser never makes a direct cross-origin request to the target URL, so there is no risk of leaking session data or triggering authenticated actions on the target server. The tool only reads and analyses the HTTP response headers returned by the target server to determine its CORS configuration. Request and response data is processed in memory on the server and is not logged or stored persistently. For complete transparency, the Raw Headers section displays the exact request and response headers exchanged during the test.
Requests are sent from our server. No cookies or credentials from your browser are transmitted.