Why is my request blocked by CORS?

It tells you why a cross-origin request is blocked by CORS — without you having to fire a live request and read cryptic console errors. You paste the request details (the Origin it comes from, the method, any custom headers, the Content-Type, and whether it sends credentials) and the server's Access-Control-* response headers. corsverdict applies the browser's CORS rules and reports whether a preflight is required, whether the request is allowed or blocked, the exact rule that fails, and the minimal correct response headers to fix it. Everything runs in your browser — nothing is uploaded.

For requests that could have side effects, the browser first sends an OPTIONS "preflight" to ask the server if the real request is allowed. A request avoids the preflight (it is "simple") only if ALL of these hold: the method is GET, HEAD, or POST; it sends no non-safelisted request headers; and any Content-Type is application/x-www-form-urlencoded, multipart/form-data, or text/plain. Use a PUT/DELETE/PATCH, send an Authorization or custom header, or send application/json, and the browser preflights first. If the preflight fails, the real request is never sent.

The response's Access-Control-Allow-Origin (ACAO) must be either "*" or an exact, byte-for-byte match of the request Origin. The Origin is just scheme + host + port — no path and no trailing slash — so "https://app.example.com/" (trailing slash) will NOT match "https://app.example.com". A different scheme (http vs https) or port is a different origin and fails too. You cannot list multiple origins in one header; if you need to allow several, read the request Origin and echo it back dynamically (and add Vary: Origin).

When a request includes credentials — cookies, HTTP authentication, or fetch with credentials: "include" — the rules tighten to prevent cross-site credential theft. Access-Control-Allow-Origin must NOT be "*"; it has to echo the exact Origin. The response must also include Access-Control-Allow-Credentials: true. And in a preflight, "*" in Access-Control-Allow-Methods or Access-Control-Allow-Headers is treated as the literal character "*", not a wildcard — so you must list the real methods and headers explicitly.

Two reasons people hit this. First, the "*" wildcard only works for non-credentialed requests; with credentials it is literal. Second — and this surprises everyone — even for non-credentialed requests, the wildcard never covers the Authorization header. Authorization must always be named explicitly: Access-Control-Allow-Headers: Authorization (plus any others). corsverdict flags this exact case because it is one of the most common "but I used a wildcard!" CORS failures.

They are the preflight's answer. Access-Control-Allow-Methods must include the method your real request will use (GET, HEAD, and POST are always allowed, even if not listed). Access-Control-Allow-Headers must include every non-safelisted request header your code sets — for example Authorization, X-Requested-With, or Content-Type when it is application/json. If the method or any header is missing, the preflight fails and the real request is blocked.

If you dynamically echo the request Origin into Access-Control-Allow-Origin (rather than sending "*"), you should also send Vary: Origin. Without it, a shared cache or CDN can store the response for one origin and then serve that same allow-origin header to a different origin — which either leaks access or, more often, breaks CORS for everyone after the first caller. corsverdict warns when you reflect the Origin but omit Vary: Origin.

CORS is enforced by browsers, not by servers or command-line tools. Postman and curl happily make the request and show you the response because they ignore CORS entirely — there is no "origin" and no same-origin policy to protect. The browser is the one that withholds the response from your JavaScript unless the Access-Control-* headers permit it. That is why a request can succeed everywhere except in your web app, and why a header-level checker like this is useful.

corsverdict implements the WHATWG Fetch standard (the CORS protocol) and covers the rules that cause the overwhelming majority of CORS failures. It evaluates statically from the headers you paste and does not make a live request, so it cannot see server-side redirects, proxies, or browser-specific quirks — always confirm against your real server and your browser's devtools Network tab. It is informational, not a security audit. On privacy: this is a static page; everything you paste is processed in your browser, never uploaded, and nothing is logged.