CORS Header Generator
Generate static CORS response headers and check supplied preflight parameters
Output configures one static origin; it does not reflect arbitrary Origin values. Multi-origin servers must validate their own allowlist. A null origin may come from a sandboxed page or local file; allow it only when intended.
Response headers and server snippets appear after generation.
Server snippets only set response headers. Place them in the correct context and configure OPTIONS responses and actual endpoints. Response status, redirects, caches, private/local network permissions and browser-specific policies are not simulated.
Copy Origin, Access-Control-Request-Method and Access-Control-Request-Headers from a browser OPTIONS request. This assumes preflight already occurred; it does not predict whether a normal request needs preflight. Enter only the non-safelisted header names listed by the browser.
The Fetch standard requires Authorization to be explicitly allowed; * alone is insufficient. Some Chrome versions behave differently. This check follows the standard and does not guarantee identical browser behavior. A CORS failure also does not prove that the request was never sent.
Configuration is processed in your browser without visiting origins or saving drafts.
The full guide also includes pitfalls, worked examples, snippets, FAQs, and related tools for checking results or troubleshooting.
About this tool
CORS Header Generator produces response headers for one static origin, allowed methods and request headers, exposed response headers, credentials and a preflight cache duration. It validates origin syntax, token lists and Max-Age, and rejects wildcard origin with credentials. The output includes Node/Express and, where representable, Nginx header statements; these statements do not implement an endpoint or answer OPTIONS by themselves. A separate check compares parameters copied from an existing browser preflight with the generated policy. It follows a limited Fetch-standard model, including safelisted methods and credential-dependent wildcard rules. It does not predict whether preflight is needed, dynamically reflect origins, contact a server or certify browser acceptance.
Production Snippets
A preflighted GET does not require GET in Allow-Methods
text
Browser preflight parameters:
Origin: https://app.example.com
Access-Control-Request-Method: GET
Access-Control-Request-Headers: x-trace
Credentials: omit
Relevant response headers:
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Headers: X-Trace
GET is a safelisted method, even when a custom header causes preflight. This example checks only the supplied parameters; it does not send OPTIONS or verify a server response.Suggested Workflow
Fix Credentialed CORS: Check Origins, Preflight and Cookies
Trace a credentialed cross-origin request through OPTIONS and the actual response, then test allowed origins, rejected origins and cookie behavior.
SameSite=None Requires Secure: Cookie Fix Playbook
Resolve cross-site login/session failures caused by cookie attribute mismatch in modern browsers.
Frequently Asked Questions
Does this implement dynamic origin reflection?
No. Output uses one static origin. For multiple origins, validate a server-side allowlist before choosing the response origin. Do not copy arbitrary request origins without a policy.
What should be entered in the preflight checker?
Use Origin, Access-Control-Request-Method and Access-Control-Request-Headers from an actual OPTIONS request. Header input is the browser-produced non-safelisted name list, not all headers from the original request.
Must GET or POST appear in Allow-Methods?
GET, HEAD and POST are CORS-safelisted methods. Within the Fetch preflight algorithm, their presence is not required in Allow-Methods; other conditions, including allowed request headers, still apply.
Can * allow Authorization or credentialed requests?
The Fetch standard requires Authorization to be listed explicitly. Wildcard method/header semantics also change with credentials: include, and a wildcard origin cannot be used with that mode. Some browser implementations differ; the check keeps the standard rule.
Are the server snippets complete CORS middleware?
No. They set headers only. Configure actual endpoints, OPTIONS status and placement yourself. Nginx output is withheld for values containing $, which Nginx would interpret as a variable. Max-Age is limited here to 0–86400 seconds, and browsers may cap it further.
What does the checker leave out?
It does not test response status, redirects, caches, cookies, private/local network permissions or browser-specific extensions. CORS failure can occur after a request was sent. No origins are contacted and no configuration drafts are stored.
Keep browsing