CORS Tester

How to use it

1. Describe the request: the origin your code runs on, the URL it calls, the method, the headers your code sets, the credentials mode, the body's Content-Type.
2. Paste the headers of the response your code reads, up to the first blank line — a network panel or a terminal transcript has them.
3. Paste the OPTIONS response separately when it differs, with its status code and its redirect state.
4. Read the trace downwards. Each row names its clause and prints its verdict as a word — Pass, Fail, Warning, Not checked — and a failing row prints the header that would satisfy it.
5. Switch to the wire view for the literal OPTIONS exchange. Copy link puts the description in the fragment.

A cross-origin call fails and the console reports only that access was blocked, never which rule decided it. Describe the request, paste the response headers, and the WHATWG Fetch decision is replayed in order: preflight or not, every check with its clause, the row that stops it, the header that clears it. Nothing is sent anywhere — the verdict comes from the pasted text.

How it works

Two origins are the same when scheme, host and port agree; an origin has no path, so a value ending in a slash is not one. When they differ the browser still sends the request, then withholds the answer unless Access-Control-Allow-Origin returns the requesting origin, a wildcard, or null. That is why a call can sit in the network panel at status 200 while the promise rejects.

Others earn an OPTIONS round trip first. A request stays simple while its method is GET, HEAD or POST, every header your code sets is one of five safelisted names inside its value limits, and the body's Content-Type is one of three values. A bearer token or a JSON body ends that, and the OPTIONS answer must arrive 2xx, unredirected, covering what was asked.

Credentials rewrite the rules rather than adding to them. Once cookies travel along, a star in any Access-Control-Allow-* header is read as a literal matching nothing, Allow-Credentials must carry the lowercase byte string true, and Authorization has to be listed by name.

Examples

POST https://api.example.com/v1/orders from https://app.example.com · Content-Type: application/json · X-Request-Id: 7 · credentials: omit

Outcome: blocked — stopped at allow-headers-covers
Preflight: yes — header-not-safelisted, content-type-not-safelisted
Readable response headers: none
Fix: Access-Control-Allow-Headers: content-type, x-request-id

GET https://api.example.com/v1/me from https://app.example.com · credentials: include · response Access-Control-Allow-Origin: *

Outcome: blocked — stopped at wildcard-vs-credentials
Preflight: no
Readable response headers: none
Fix: Access-Control-Allow-Origin: https://app.example.com

GET https://api.example.com/v1/orders from https://app.example.com · exact Access-Control-Allow-Origin · Expose-Headers: X-Total-Count

Outcome: allowed-with-warnings
Preflight: no
Readable response headers: x-total-count

Every example on this page is executed against the same engine that powers the tool, on every build.

Common errors

The response sends no Access-Control-Allow-Origin header, so the browser refuses to let your code read it. This is the "No 'Access-Control-Allow-Origin' header is present on the requested resource" message in the console. (Fetch, CORS check.)

The commonest failure: the header must ride the response your code reads, not only the OPTIONS answer.

The preflight answered 302. A preflight is only accepted with an ok status, 200 to 299, so the browser stops here and your real request is never sent. A redirect on a preflight is a network error for the browser, even to the same path with a trailing slash. (Fetch, CORS preflight fetch.)

Authentication middleware and path canonicalisation both cause it: OPTIONS arrives unauthenticated by design.

Access-Control-Allow-Headers: * does not cover authorization. It is a CORS non-wildcard request-header name, so the wildcard cannot be relied on to cover it: shipping browsers differ, at least one accepts it when the request sends no credentials, and none accept it once credentials are included. This is why a config that looks permissive still blocks an authenticated call. (Fetch, CORS non-wildcard request-header name.)

The star reads as maximally permissive and is not: signed-in routes fail while public ones keep working.

The response sends Access-Control-Allow-Credentials: TRUE. The check compares the value to the byte string true, in lower case, so TRUE does not enable credentials and the response is blocked. (Fetch, CORS check.)

A boolean coerced by a template or a config loader lands here; there is no parsing step.

The response allows https://app.example.com/, but this request comes from https://app.example.com: the allowed value has a trailing slash, and an origin never has a path — not even /. (Fetch, CORS check.)

Copied from an address bar, which shows the slash, into a setting that wants an origin. Serialised origins are compared byte for byte.

"app.example.com" is not an origin. An origin is a scheme, a host and an optional port — https://app.example.com — or the literal null for a sandboxed document.

A refusal from the form, not a verdict about your configuration: with no scheme, nothing to compare.

Keyboard shortcuts

⌘/Ctrl + Enter

Re-run the simulation as described.

⌘/Ctrl + C

Copy the pane on screen, nothing selected.

⌘/Ctrl + Shift + C

Copy the pane whatever is selected.

⌘/Ctrl + S

Download the pane on screen, not the page.

t

Step to the next theme.

? or ⌘/Ctrl + /

List these shortcuts.

Esc

Close the overlay on top.