snaptools
chain
⇄
CORS Checker

Nothing is fetched and nothing is sent anywhere — the verdict is computed from the Fetch standard's rules, in this tab. That is why it works for an API on localhost, behind a VPN, or behind a login.

// about this tool

CORS Checker Online

Updated 2026-08-04

// how to use

  1. 1 Open your browser's Network tab, click the failing request, and copy its response headers.
  2. 2 Paste them here, then set the origin your page runs on and how the request was made.
  3. 3 Read the verdict — it names the one rule that failed and what to send instead.

// examples

The wildcard-with-credentials mistake
Input
access-control-allow-origin: *, credentials: include
Output
Blocked — "*" cannot be used with credentials. Echo the exact origin instead.
A trailing slash
Input
access-control-allow-origin: https://app.example.com/
Output
Blocked — an origin never has a trailing slash, and the match is byte-for-byte.
Authorization under a wildcard
Input
access-control-allow-headers: * with an Authorization request header
Output
Blocked — the wildcard does not cover Authorization; it has to be named.

// common uses

Working out which CORS rule blocked a request, rather than guessing Debugging an API on localhost or behind a VPN, where URL-fetching checkers cannot reach Checking a config change before deploying it Understanding why a request preflights when you did not expect it to

// faq

Why does this not just fetch my URL like other CORS checkers?
Because fetching it would answer a different question. A tool that requests your endpoint from its own server sees what ITS server sees, not what YOUR browser sees, and it cannot reach an API on localhost, behind a VPN, or behind a login — which is where most CORS problems actually live. A CORS verdict is pure rule-matching on headers you already have, so pasting them is both sufficient and strictly more useful.
Why does my request fail in the browser but work in curl or Postman?
Because CORS is enforced by browsers, not servers. curl and Postman do not implement it, so they will happily show you a successful response for a request your browser refuses to let JavaScript read. A working curl tells you the server is fine; it tells you nothing about CORS.
Why can't I use a wildcard when I send cookies?
Because the combination would let any site on the internet make authenticated requests as your logged-in users and read the replies. When the request carries credentials the browser requires an exact origin and `Access-Control-Allow-Credentials: true`. Echo back the requesting origin after checking it against your own allowlist, and add `Vary: Origin` so caches do not mix responses up.
Why does my POST send an OPTIONS request first?
That is the preflight. A request escapes it only if the method is GET, HEAD or POST, every header is CORS-safelisted, and the Content-Type is one of `application/x-www-form-urlencoded`, `multipart/form-data` or `text/plain`. Sending JSON, or any custom header, means `application/json` or that header triggers a preflight — and the OPTIONS response must answer 2xx before your auth middleware runs.
I set Access-Control-Allow-Headers to * and Authorization is still blocked. Why?
This is the most-missed rule in CORS. The Fetch standard excludes `Authorization` from the `*` wildcard by name, even for requests that send no credentials, so that a wildcard policy cannot accidentally allow distributed brute-forcing of credentials. You have to list `Authorization` explicitly.

// works with your data

HTTP Status Codes URL Parser JWT Decoder cURL Converter MIME Type Lookup

Use this via API

Get a free API key → 
curl -X POST https://thesnaptools.com/api/v1/tools/cors-checker \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"headers":"access-control-allow-origin: *, credentials: include"}'
Esc
↑↓ navigate ↵ open Esc close