Interactive Diagnostic

CORS Preflight Simulator

Test whether a cross-origin browser request triggers an automatic OPTIONS preflight, preview the required server response headers, and generate secure server configuration snippets.

Zero-Log Simulation: Runs entirely in your browser. Nothing leaves this page.
Quick Scenarios:

1. Endpoints & Origin

The scheme, hostname, and port of the frontend application.
The destination endpoint requested by fetch() or Axios.

2. Request Parameters

Non-safelisted headers sent in the actual request.
PREFLIGHT REQUIREDCROSS-ORIGIN

OPTIONS Preflight Triggered

Why is preflight required?

Simulated Browser Preflight RequestHTTP / OPTIONS
Evaluating...
Required Server Response (RFC Compliant)HTTP / 204 No Content
Evaluating...

Server Configuration Recipes

Loading config...

How Browsers Evaluate CORS Preflight Requests

According to the W3C Fetch and WHATWG specifications, a web browser automatically sends an HTTP OPTIONS preflight request before executing the actual network call whenever a cross-origin request does not meet the criteria of a CORS-Simple Request.

1. Simple vs. Non-Simple Methods

The browser considers only GET, HEAD, and POST to be CORS-safelisted methods.

Mutating HTTP verbs such as PUT, DELETE, and PATCH always trigger an automatic preflight request before data transmission.

2. Content-Type Restrictions

Only three MIME types are CORS-safelisted for request bodies:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

Sending application/json triggers an OPTIONS preflight check by design.

3. Custom Headers Authorization

Any non-standard request headers (e.g., Authorization, X-Request-ID, X-Api-Key) require explicit server pre-approval via the Access-Control-Allow-Headers response header.

Frequently Asked Questions

Why does Wildcard (*) fail with credentials?

The W3C Fetch specification strictly forbids Access-Control-Allow-Origin: * whenever credentials: 'include' or withCredentials = true is set. If credentials (cookies, client TLS certificates, or Authorization headers) are transmitted, the server must return the exact matching origin (e.g., Access-Control-Allow-Origin: https://app.example.test) along with Access-Control-Allow-Credentials: true.

Why must servers return the Vary: Origin header?

When a backend dynamically generates the Access-Control-Allow-Origin header based on the incoming request, intermediary shared caches and CDNs must be instructed to cache separate responses for each origin. Omitting Vary: Origin can lead to CDN cache poisoning where one origin receives CORS headers cached for another.

How can I cache the preflight OPTIONS response?

Servers can instruct browsers to cache the preflight approval result by returning the Access-Control-Max-Age header (e.g., Access-Control-Max-Age: 86400 for 24 hours). This eliminates redundant OPTIONS requests on subsequent calls.