Text & documents
Numbers & maths
Data & formats
Security
Development & DevOps
Artificial Intelligence
Finance
Health & Wellness
Productivity
Games & Entertainment
Multimedia & design
Business
How to use
What it is and what it's for

CORS (Cross-Origin Resource Sharing) is the mechanism by which a browser decides whether a web page may read the response of an API hosted on another origin (another domain, port or protocol). Without the right CORS headers, the browser blocks the read for security. This tool simulates that browser check: it explains, without making any real request and all in your browser, whether your server would allow the call and why.

What to enter

Fill in three things:

Origin (browser) — the URL of the app making the request (e.g. https://myapp.com). It is the value the browser would send in the Origin header.
HTTP methodGET, POST, PUT, DELETE… The method decides whether a preflight is needed.
Server response headers — paste the headers your API returns, one per line, in the format Name: value (e.g. Access-Control-Allow-Origin: *). The analysis updates on its own as you type.

Simple request vs preflight

There are two kinds of cross-origin request:

Simple request — with GET, POST or HEAD and basic headers, the browser sends it directly and then checks whether the response carries Access-Control-Allow-Origin.
With preflight — with methods like PUT, PATCH or DELETE (or custom headers), the browser first sends a preliminary OPTIONS request to ask permission. The tool automatically flags when your method requires a preflight.

The preflight (OPTIONS) in detail

The preflight is an OPTIONS request the browser sends before the real one to ask “will you let me do this?”. In this tool it fires with the methods PUT, PATCH, DELETE and OPTIONS. When the notice appears, your server must respond to that OPTIONS with the right CORS headers (allowed origin, methods and headers); otherwise the browser cancels the real request even if your API works. Adding Access-Control-Max-Age avoids repeating the preflight on every call.

Access-Control-Allow-Origin

It is the essential header: it states which origin may read the response.

* — allows any origin, but does not work with credentials (cookies).
• A specific origin, e.g. https://myapp.com — only that origin, and it must match exactly your Origin (protocol + domain + port).

If this header is missing, or its value matches neither * nor your origin, the request is blocked.

Access-Control-Allow-Methods

Lists the HTTP methods the server accepts from another origin, comma-separated (e.g. GET, POST, PUT, DELETE). It matters mostly in the preflight. If you provide this header but it does not include your method, the tool flags it as a problem and blocks the request. If you omit it, the method is not checked.

Access-Control-Allow-Headers

Lists which request headers the client may send (e.g. Content-Type, Authorization). The browser requires it in the preflight when your request sends non-standard headers. If your app sends Authorization and it does not appear here, the browser will block the call.

Access-Control-Allow-Credentials

With the value true it allows sending cookies and credentials on the cross-origin request.

Heads up, important gotcha: credentials are incompatible with Access-Control-Allow-Origin: *. If you use credentials, the origin must be specific (e.g. https://myapp.com), never *. Combining the two makes the browser reject the response.

Access-Control-Max-Age and Vary

Access-Control-Max-Age states how many seconds the browser may cache the preflight response (e.g. 86400 = 24 h), so it doesn't repeat the OPTIONS on every call. The tool includes it in the suggested headers when your method needs a preflight. Remember to also add Vary: Origin on your server when you return a specific origin, so caches don't mix responses from different origins.

How to read the result

After the analysis you will see:

• A banner, green (allowed) or red (blocked), with the exact reason: Access-Control-Allow-Origin is missing, the origin doesn't match, or the method isn't allowed.
CORS headers found — each detected header with its value and an explanation.
Problems detected — what prevents the request.
It works, but it is a security risk — what the browser DOES let through and you should not want, such as accepting the null origin with credentials.
Your browser allows it, but do not rely on it — what Chrome accepts today and the spec does not guarantee.
Suggested headers — a block ready to copy into your server configuration.

CORS ExplainerAnalyse your server's CORS headers
CORS ExplainerAnalyse and explain your server's CORS headers
URL of the app making the request

Tick it if your code uses <code>credentials: 'include'</code> (or <code>withCredentials</code>). It changes the rules: the origin can no longer be <code>*</code>, wildcards stop working, and the server must answer <code>Access-Control-Allow-Credentials: true</code>.

The REQUEST ones, not the response ones. They decide whether the browser sends an OPTIONS first, and they are what "Access-Control-Allow-Headers" has to cover.

CORS permitido correctamente
The browser will first send an OPTIONS request (preflight), because of the Content-Type application/json. Your server has to answer THAT OPTIONS too, not only the real request.

CORS headers found

Access-Control-Allow-Originhttps://myapp.comPermite solo el origen: https://myapp.com
Access-Control-Allow-MethodsPOSTMétodos permitidos: POST
Access-Control-Allow-HeadersContent-TypeCabeceras permitidas en la petición: Content-Type

Suggested headers for your server

Access-Control-Allow-Origin: https://myapp.com
Vary: Origin
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400
This is decided from the headers you paste, without touching the network - which is why it also works for a local or private API. If you want to fire the request FOR REAL and see whether your server answered at all, there is the API workbench.