CORS Header Generator: Get Access-Control-* Headers Right the First Time
CORS errors are notoriously confusing to debug from the browser console alone — the message tells you a request was blocked, not which specific header combination is wrong. This generator builds a correct set of Access-Control-* response headers from a form, and flags the single most common CORS mistake — combining a wildcard origin with credentials — before you even copy the output.
Allow-Origin: * cannot be combined with Allow-Credentials: true — browsers reject this combination outright.
The Wildcard + Credentials Conflict
This is the single most common CORS configuration mistake: setting Access-Control-Allow-Origin: * while also trying to allow credentials (cookies, HTTP auth) on cross-origin requests. Browsers block this combination unconditionally as a security measure — you must specify the exact trusted origin instead of a wildcard whenever credentials are involved.
Why Some Requests Trigger a Preflight and Others Don't
'Simple' requests (GET/HEAD/POST with only a few standard headers and content types) skip the preflight and go straight through, checked against the response headers after the fact. Anything else — PUT, DELETE, custom headers like Authorization, non-standard content types — triggers a preflight OPTIONS request first, which the browser checks against Allow-Methods and Allow-Headers before sending the real request.
Response Header Visibility Is Opt-In
By default, JavaScript in the browser can only read a small safelist of response headers on a cross-origin response (things like Content-Type, Content-Length). Any custom header your API wants client-side JS to actually read — like a request ID or rate-limit count — must be explicitly listed in Access-Control-Expose-Headers.
Practical Examples
A Public, No-Credentials API
Simple wildcard access.
- 1.Allow all origins: checked
- 2.Credentials: unchecked
- 3.Result: Access-Control-Allow-Origin: *
An Authenticated Cross-Origin App
Requires a specific origin, not a wildcard.
- 1.Origin: https://app.example.com
- 2.Credentials: checked
- 3.Result: specific origin + Allow-Credentials: true
Headers This Generator Builds
- Access-Control-Allow-Origin
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Allow-Credentials
- Access-Control-Expose-Headers
- Access-Control-Max-Age
Good Use Cases
- Configuring CORS for a new API endpoint
- Debugging a wildcard/credentials CORS rejection
- Understanding which headers a preflight actually checks
- Generating a starting config to translate into your server framework's syntax
Frequently Asked Questions
Why can't I use Access-Control-Allow-Origin: * with credentials?
It's a security restriction browsers enforce: if a server would send cookies/credentials on a cross-origin response, it must explicitly name the trusted origin — allowing literally any site (*) to receive credentialed responses would defeat the purpose of the same-origin policy entirely.
What does Access-Control-Allow-Methods actually control?
It tells the browser which HTTP methods the server permits for cross-origin requests to this resource. For 'non-simple' requests (like PUT, DELETE, or requests with custom headers), the browser sends a preflight OPTIONS request first and checks this header before sending the real request.
What's the difference between Allow-Headers and Expose-Headers?
Access-Control-Allow-Headers lists which request headers the client is permitted to send (relevant during preflight). Access-Control-Expose-Headers lists which response headers JavaScript running in the browser is allowed to read — by default, only a small safelist of response headers is readable cross-origin.
What does Access-Control-Max-Age do?
It tells the browser how long (in seconds) it can cache the result of a preflight OPTIONS request, avoiding a repeated preflight round-trip for every actual request within that window. Longer values reduce preflight overhead but delay how quickly permission changes take effect.
Do I need CORS headers for same-origin requests?
No — CORS only applies to cross-origin requests (different scheme, domain, or port than the page making the request). Same-origin requests are never subject to CORS restrictions in the first place.
Does setting these headers actually enable CORS on my server?
This tool only generates the header text — you still need to configure your actual server, framework, or API gateway to send these headers on responses. The specific configuration method varies by what you're running (Express, Nginx, a cloud API gateway, etc.).