CORS Preflight Debugger
Understand why a cross-origin request succeeds or fails, and generate safer CORS configuration guidance.
Debugger
Results
Simulation steps
Issues and guidance
Introduction
Cross-Origin Resource Sharing controls how browsers allow web pages to request resources from different origins. When a request is not simple, the browser sends an OPTIONS preflight request before the actual request.
This debugger helps you reason about preflight triggers and server header requirements without exposing your API to repeated trial-and-error requests.
How it works
The tool evaluates the request method, headers, content type, credentials, and server CORS headers. It then explains whether a preflight request is required and whether the simulated server response would allow the actual request.
- No network request is made by the tool.
- Header parsing is performed locally.
- Credentials and wildcard combinations are checked conservatively.
- Generated snippets are starting points, not deployment guarantees.
How to use
- Enter the request method and target URL.
- Enter the requesting page origin.
- Add custom headers and content type if relevant.
- Enter the server’s CORS response headers.
- Run the simulation and review the explanation.
- Copy the client or server guidance snippets.
Practical example
A POST request with Content-Type: application/json and a custom
X-Api-Key header is not a simple request. The browser will send a
preflight request asking whether POST, Content-Type, and X-Api-Key are allowed.
Use cases
- Debugging failed API calls from front-end apps.
- Reviewing CORS headers before deployment.
- Understanding why preflight requests occur.
- Preparing API documentation for front-end consumers.
- Auditing credential and wildcard usage.
Best practices
- Allow only the origins your application needs.
- Avoid wildcard origins when credentials are used.
- List required headers explicitly for credentialed requests.
- Use Access-Control-Max-Age to reduce repeated preflights.
- Return CORS headers on both preflight and actual responses where required.
Common mistakes
- Using
*with cookies or authentication. - Forgetting to allow custom headers.
- Allowing a method but not OPTIONS.
- Setting CORS headers only on the preflight response.
- Assuming JSON POST requests are simple requests.
Limitations
- The tool does not fetch live endpoints.
- It cannot inspect real server behavior or TLS configuration.
- Browser implementations may differ for edge cases.
- Complex proxy or gateway behavior may require live testing.
Browser compatibility
CORS is supported by all current major browsers. Preflight behavior follows the Fetch specification, but server and proxy configuration can affect real-world results.
FAQ
Does this tool call my API?
No. The simulation is fully local and does not send network requests.
Why does my JSON POST trigger preflight?
Because application/json is not one of the simple CORS content types.
The browser asks the server for permission before sending the actual request.
Can I use wildcard origin with cookies?
No. When credentials are included, the server should return the specific allowed
origin and set Access-Control-Allow-Credentials: true.
Do CORS headers apply to same-origin requests?
CORS is not required for same-origin requests. The tool flags same-origin cases and explains that CORS does not apply.