No Login Data Private Local Save

CORS Header Debugger - Online Check Cross‑Origin Access

6
0
0
0

CORS Header Debugger

Test, analyze & debug Cross-Origin Resource Sharing headers in real-time

Live Testing
Request Tester
Response & CORS Analysis
Send a request to see the CORS analysis here
Response Header Analyzer

Paste raw response headers (from curl -I or DevTools) to analyze CORS configuration.

Quick Reference
Access-Control-Allow-OriginAllowed origin or *
Access-Control-Allow-MethodsGET, POST, PUT, DELETE...
Access-Control-Allow-HeadersContent-Type, Authorization...
Access-Control-Allow-Credentialstrue / false
Access-Control-Max-AgeSeconds (e.g. 86400)
Access-Control-Expose-HeadersX-Custom-Header, Link...
Frequently Asked Questions

CORS (Cross-Origin Resource Sharing) is a browser security mechanism that controls how web pages can request resources from a different domain than the one that served the page. Without proper CORS headers, browsers block cross-origin requests for security reasons. Understanding and correctly configuring CORS is essential for any API that serves multiple client domains.

This error means the server response is missing the Access-Control-Allow-Origin header. To fix it, configure your server to include this header with either a specific origin (e.g., https://myapp.com) or a wildcard *. Note that * cannot be used with credentials (cookies/authorization). Use this tool to verify the header is present in the response.

A preflight request is an automatic OPTIONS request sent by the browser before certain cross-origin requests (non-simple requests). It checks with the server whether the actual request is safe to send. Preflight is triggered by non-standard HTTP methods (PUT, DELETE, PATCH), custom headers (like Authorization or X-Custom-Header), or Content-Type values other than application/x-www-form-urlencoded, multipart/form-data, or text/plain.

No. The CORS specification prohibits using the wildcard * together with Access-Control-Allow-Credentials: true. If you need to send credentials (cookies, HTTP authentication), you must specify an exact origin in Access-Control-Allow-Origin. Using both is a common configuration mistake that this tool can detect.

Use curl with the -I flag for a HEAD request: curl -I -H "Origin: https://example.com" https://api.target.com/endpoint For preflight simulation: curl -X OPTIONS -H "Origin: https://example.com" -H "Access-Control-Request-Method: POST" https://api.target.com/endpoint Then paste the response headers into the Header Analyzer above.

GET requests are considered "simple requests" under CORS rules (if they don't include custom headers or non-standard content types). POST requests with Content-Type: application/json or custom headers trigger a preflight because they fall outside the "simple request" criteria. The browser sends an OPTIONS request first to verify the server permits the actual POST. Ensure your server handles OPTIONS requests properly.

By default, browsers only expose a limited set of "simple response headers" to JavaScript (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma). If your API returns custom headers (like X-Rate-Limit, X-Request-ID, or Link), you must list them in Access-Control-Expose-Headers for JavaScript to read them via response.headers.get().

The Access-Control-Max-Age header controls how long (in seconds) a browser can cache the preflight response. The maximum value in Chrome is 7200 seconds (2 hours), while Firefox supports up to 86400 seconds (24 hours). Setting an appropriate Max-Age reduces unnecessary preflight requests and improves performance. If not specified, browsers use a default of 5 seconds.