CORS Preflight Simulator

Overview

The CORS preflight simulator predicts whether a browser will allow a cross-origin request, without making any network calls. Enter the request method, headers, and origin you plan to send, plus the server's Access-Control-Allow-* response headers, and the simulator returns the same verdict the browser would: allowed, blocked, or no preflight required.

Frontend developers debugging a CORS error in console, API designers tuning their Access-Control-Allow-Headers, and security engineers reviewing a third-party widget all need a way to reason about preflights offline. Long-tail keywords covered: simulate CORS preflight OPTIONS request, why is my fetch blocked by CORS, and which headers trigger preflight.

How it works

Cross-Origin Resource Sharing is defined by the Fetch standard. When a script makes a request that is not "simple" — a non-GET/POST method, custom headers, or a non-form Content-Type — the browser first sends an OPTIONS preflight to the target URL. The preflight includes Origin, Access-Control-Request-Method, and Access-Control-Request-Headers. The server replies with Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and optionally Access-Control-Max-Age.

The browser then compares the response against the request. The origin must match (or be *, but not if credentials are involved), the method must be allowed, every custom header must be allowed, and credentials are only permitted when Access-Control-Allow-Credentials: true is paired with a non-wildcard origin. Any mismatch aborts the actual request.

Examples

• GET to /api/data with no custom headers from https://app.example.com → no preflight, browser allows the request if the response carries Access-Control-Allow-Origin: *.
• PUT with Content-Type: application/json → preflight required; the server must list PUT in Access-Control-Allow-Methods and Content-Type in Access-Control-Allow-Headers.
• Cookied POST with credentials: 'include' from https://app.example.com → server must return Access-Control-Allow-Origin: https://app.example.com and Access-Control-Allow-Credentials: true.
• Custom X-Tenant-Id header → preflight required even on GET; the header must appear in Access-Control-Allow-Headers.

FAQ

Which requests are "simple" and skip the preflight?

GET, HEAD, and POST with Content-Type of application/x-www-form-urlencoded, multipart/form-data, or text/plain, and no custom headers beyond a short safelist.

Why does Access-Control-Allow-Origin: * not work with cookies?

The Fetch spec explicitly disallows wildcards when credentials: 'include' is set. Echo the request origin instead.

What does Access-Control-Max-Age do?

Caches the preflight result for up to the specified seconds, so subsequent requests skip the OPTIONS round trip. Browsers cap it at a few hours regardless of what the server sends.

Does CORS protect my server?

No. CORS is a browser policy. Anything that bypasses the browser — curl, server-to-server requests, mobile apps — can still hit your endpoint. Use server-side authentication for real protection.

Try CORS Preflight Simulator