CORS Response Simulator
Model an ordinary browser CORS exchange with the headers you supply. See whether an OPTIONS preflight is needed, whether the actual request is sent and whether script can read the final response.
Key features
- Compare the script origin with the target URL's scheme, host and port
- Derive a preflight from method and CORS-unsafe author request headers
- Test OPTIONS status, allowed origin, credentials, methods and headers separately
- Distinguish a blocked preflight from an actual request whose response is unreadable
- Load success, wildcard-with-credentials and simple GET examples without contacting a server
How to use
- Enter the script origin, full target URL, method, credentials mode and author request headers.
- Enter the proposed OPTIONS response status and Access-Control-Allow-* headers.
- Enter the proposed actual response status and Access-Control-Allow-* headers.
- Run the simulation and read the step-by-step reason for each stage.
Use cases
- Understand why a credentialed fetch fails with Access-Control-Allow-Origin: *.
- Check whether a JSON POST requires OPTIONS and which names appear in Access-Control-Request-Headers.
- Find a missing explicit Authorization allowance or method spelling mismatch.
- Show why a server's 403 response may still be readable while a failed preflight sends no actual request.
Frequently asked questions
Does this send an OPTIONS or fetch request?
No. It evaluates only the text entered in your browser. Network errors, redirects, cache entries, private-network access, service workers and browser extensions are outside this model. Confirm the final behavior in a real browser and server logs.
Why does Access-Control-Allow-Origin: * fail with credentials?
Fetch's CORS check accepts the wildcard only when credentials mode is not include. With include, the response must name the serialized request origin and return Access-Control-Allow-Credentials: true on both a needed preflight and the actual response.
Are method and header names compared with the same case rules?
No. Fetch first uppercases DELETE, GET, HEAD, OPTIONS, POST and PUT. Access-Control-Allow-Methods then uses the effective method's exact spelling, while allowed request header names are compared without case. Extension methods such as PATCH retain their entered case.
If the tool says blocked, did the server receive the request?
A failed preflight prevents the actual request. Without a preflight, or after a successful one, the actual request can reach the server even if its response fails the final CORS check. CORS is a browser read-access protocol, not a server authorization rule.
What is intentionally not modeled?
This bounded profile handles HTTP(S) CORS-mode requests with ordinary methods and ASCII author headers. It does not model redirects, 304/407 responses, preflight cache, forced preflight for streaming bodies, request body, response-header exposure, private-network access, mixed content or server authentication. Complex MIME parameters can be conservatively treated as unsafe.
Privacy
Header text stays in this browser tab's memory. The simulator sends no requests, uploads nothing and keeps no automatic copy. Avoid pasting real credentials or secrets; do not share screenshots containing private headers.
Comments & questions