What does Access-Control-Allow-Origin control?

It names which origin may read the response from a cross-origin request. A specific origin like https://app.example.com is precise, while * allows any origin to read the response, which is only safe for genuinely public, non-credentialed resources.

Why is wildcard origin with credentials forbidden?

Browsers refuse to expose a response when Access-Control-Allow-Origin is * and Access-Control-Allow-Credentials is true. Sending credentials to any origin would let any site read authenticated responses, so the combination is blocked outright.

What is Access-Control-Max-Age for?

It tells the browser how many seconds it may cache the preflight (OPTIONS) result, reducing repeated preflights. A larger value improves performance but delays picking up changes to your CORS policy.

Does Allow-Origin alone expose every header?

No. By default the browser only exposes a small set of simple response headers to scripts. To let JavaScript read custom headers you must list them in Access-Control-Expose-Headers.

Is anything sent to a server?

No. The headers you paste are parsed entirely in your browser. Nothing is transmitted, so you can analyse internal or production headers safely.

What is the CORS Header Explainer & Validator?

Parse pasted Access-Control-Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials, Max-Age, and Expose-Headers values into a plain-English explanation of exactly which origins, methods, and headers are permitted, and flag dangerous combinations like wildcard origin with credentials. It runs free in your browser on Gera Tools, with nothing uploaded.

CORS Header Explainer & Validator

Name: CORS Header Explainer & Validator
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Cross-Origin Resource Sharing (CORS) is the browser mechanism that decides whether JavaScript on one origin may read a response from another. It is controlled entirely by Access-Control-* response headers, and small mistakes can either break legitimate requests or open serious security gaps. This tool parses pasted CORS headers and explains in plain English exactly what they permit — and flags dangerous combinations that browsers will reject or that would expose authenticated data.

The six CORS response headers

The tool reads and interprets each recognised header against the CORS specification:

Header	What it controls
`Access-Control-Allow-Origin`	Which origin(s) may read the response — a specific origin or `*` for any
`Access-Control-Allow-Methods`	HTTP methods permitted on the actual request (POST, PUT, DELETE, etc.)
`Access-Control-Allow-Headers`	Request headers the client may include (e.g. `Authorization`, `Content-Type`)
`Access-Control-Allow-Credentials`	Whether cookies, auth headers, or TLS client certs are allowed — must not be `true` with a wildcard origin
`Access-Control-Max-Age`	Seconds the browser may cache the preflight result before re-checking
`Access-Control-Expose-Headers`	Response headers JavaScript is allowed to read (by default only a small safe set is visible)

Validation rules the tool enforces

Several combinations are outright invalid under the CORS spec:

Wildcard + credentials: Access-Control-Allow-Origin: * combined with Access-Control-Allow-Credentials: true is rejected by all major browsers. The browser will not expose the response to JavaScript. The fix: echo the specific requesting origin instead of * when credentials are involved.
Allow-Headers: * with credentials: Also invalid — the wildcard for headers cannot be used alongside credentials.
SameSite=None cookies on CORS requests: The cookie must also be Secure or it will be dropped, silently breaking authenticated cross-origin calls.

Worked example

Paste these headers and the tool raises a warning:

Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true

Explanation: any origin may attempt to read the response, but because credentials are also allowed, browsers will block the response — this combination is forbidden. The corrected headers for an authenticated API:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 600

This allows only one specific origin, which the server must generate dynamically from an allowlist matching the incoming Origin request header.

Common debugging scenarios

CORS error on a credentialed fetch: Almost always * origin with credentials — switch to echoing the specific origin.
Preflight failing on a custom header: The header must be listed in Allow-Headers. Authorization is the most frequently forgotten.
Custom response header not readable by JS: Add it to Access-Control-Expose-Headers. Response headers are hidden from scripts by default unless explicitly exposed.

Nothing you paste leaves your browser — the parsing and validation run entirely in JavaScript on your device.