http.app
Zero Data Retention

CORS CHECKER

Describe the cross-origin request your page makes, paste the response headers the server sent, and get the verdict the browser would reach, step by step, with the same reason the console would print.

Zero retention: your headers never leave this browser. Verify it yourself in DevTools.

Loading the workbench.

About the CORS checker

How Can You Verify That Nothing Leaves This Browser?

You do not have to take our word that your headers stay here. Developer tools show every request a page makes, so you can watch this page work and confirm that nothing is sent. The check takes under a minute.

  1. Open your browser developer tools with F12, or Cmd+Option+I on a Mac, and select the Network tab.
  2. Reload the page and let it finish. You will see the page's own files, its web fonts, and one anonymous page-view request. Nothing has been typed yet, so none of them can contain your headers.
  3. Click the clear icon in the Network tab so that the log is empty.
  4. Paste real headers into any lane and read the result.
  5. Look at the Network tab again. It is still empty. For extra proof, turn on offline mode after the page loads and every lane keeps working.

Only two things can add a line to that log, and neither carries your headers. Submitting the feedback form sends the vote and comment you typed. Typing characters in a script the page has not displayed yet, such as Cyrillic or Greek, can make the browser fetch the matching font file, and that request names only the font.

2http never sends a request on your behalf: the request builder writes code for you to run, and the meta inspector reads source you paste instead of fetching a URL. The production site also sends a Content-Security-Policy header that tells your browser to refuse connections to anywhere except this site and the anonymous analytics endpoint.

When Does a Request Need a Preflight?

A cross-origin request goes straight to the server only if it is simple. Anything else is preceded by an OPTIONS preflight that asks permission first. The checker applies the Fetch Standard rules and tells you which part of your request triggers the preflight:

  • The method is not GET, HEAD, or POST.
  • A header is set that is not on the CORS safelist, such as Authorization or X-Api-Key.
  • Content-Type is not application/x-www-form-urlencoded, multipart/form-data, or text/plain, so JSON always needs a preflight.

What Does the Browser Check?

  1. The preflight response has a 2xx status.
  2. Access-Control-Allow-Origin is exactly the requesting origin, or * for requests without credentials. Only one value is allowed.
  3. With credentials, Access-Control-Allow-Credentials is exactly true and the origin is not *.
  4. Access-Control-Allow-Methods covers the method, and Access-Control-Allow-Headers covers every non-safelisted header.
  5. The actual response repeats a valid Access-Control-Allow-Origin, and Allow-Credentials when needed.

Each failure is shown with the wording the browser console uses, so you can match it to the error you are seeing.

What Are the Common CORS Traps?

Several rules catch experienced developers. The * wildcard in Allow-Headers and Allow-Methods does not apply to credentialed requests, and in Allow-Headers it never covers Authorization, which must be listed by name. Origins are compared as exact strings, so a trailing slash or a different letter case fails. Allowing the null origin is risky because sandboxed iframes send it.

The checker also warns when an echoed origin is missing Vary: Origin, when no Access-Control-Max-Age makes every request pay for a preflight, and which response headers JavaScript can actually read.

Is CORS a Security Feature for My Server?

Not directly. CORS is enforced by the browser to protect users: it decides whether a script on one site may read a response from another. The request may still reach your server. Server-side authorization still has to be correct; CORS only relaxes the same-origin policy, it never adds protection beyond it.

What Other Lanes Are in the Decode Section?

  • Header decoder: Paste raw request or response headers and get every header explained, with secrets masked.
  • Cookie decoder: Decode a Cookie header or Set-Cookie lines: lifetime, scope, SameSite, prefixes, and risks.
  • Cache-Control decoder: Cache-Control directives, freshness math for browser and CDN, and ETag revalidation.
  • User-agent parser: Browser, engine, OS, device, and bot detection from a pasted User-Agent string.

Elsewhere in 2http: Security header audit, Request builder, Meta tag generator, HTTP status codes, MIME types, and all eleven lanes on the 2http home page. Part of the 2suite.io privacy-first ecosystem.

Frequently Asked Questions

Why does my request work in curl but fail in the browser?

curl does not enforce CORS; only browsers do. The server must return the right Access-Control headers for the browser to let your page read the response.

Can I use Access-Control-Allow-Origin with credentials and a wildcard?

No. With credentials the server must return the exact requesting origin and Access-Control-Allow-Credentials: true. Browsers reject the wildcard in that case.

Why does my JSON POST send an OPTIONS request first?

Content-Type: application/json is not one of the three simple content types, so the browser sends a preflight to ask permission before the real request.

Does the checker send any requests?

No. It evaluates the headers you paste against the Fetch Standard rules in this tab. It never contacts your server.

Was this helpful?