VoriTools

CORS Preflight Header Analyzer

Model the request with the available fields. No request is sent; server behavior and header-value restrictions need separate testing.

Runs locally in your browser
View category: API Development (15)
This tool processes all data locally in your browser.
Browser request and copied response headersThis checker models browser rules only; it does not contact the API or replay credentials.

Model a browser CORS request against copied response headers

This checker models one browser CORS request against the response headers you paste. It answers a single question: would a browser let the page read that response, and would the preflight, where one is needed, be accepted?

Everything runs in the tab. No request is sent, so the summary describes what the copied headers permit; it does not prove what the live server returns today.

  1. Enter the request origin (scheme, host, port) and choose the method. PUT, PATCH and DELETE trigger a preflight; GET, HEAD and POST usually do not.
  2. List the headers the browser would name in Access-Control-Request-Headers, for example Authorization, X-Request-ID, and tick credentials when the request sends cookies or HTTP auth.
  3. Paste the whole response header block as `Name: value` lines and press Analyze CORS policy.
  4. Read the decision first, then the checks: every line names the header that allowed or blocked the request. Copy or download the summary to keep it.

How the checker reads Access-Control headers and where it stops

Origin matching and credentials

Access-Control-Allow-Origin has to repeat the request origin exactly: lower-case scheme and host, default ports dropped, no trailing slash. Chrome rejects `https://app.example.com/` for the origin `https://app.example.com`, and the checker reports the same mismatch.

`*` allows any origin only when the request sends no credentials. With cookies or HTTP auth the response must repeat the origin and add `Access-Control-Allow-Credentials: true`; the wildcard origin is then blocked even though it looks permissive.

What needs a preflight, and what passes without one

A JSON Content-Type or any custom header makes the browser send an OPTIONS preflight before the request. Chrome then needs a matching Access-Control-Allow-Methods entry and an Access-Control-Allow-Headers entry for every header you listed; without them the response is blocked, while `text/plain` on the same policy passes.

GET, HEAD and POST are safelisted methods: they pass the preflight even when Access-Control-Allow-Methods does not list them. PUT, PATCH and DELETE must be listed. Method and header names are compared case-insensitively: `post` and `x-test` both match.

Wildcards that stop working with credentials

`Access-Control-Allow-Methods: *` and `Access-Control-Allow-Headers: *` are wildcards only for requests without credentials. A credentialed request must find its method and every header listed literally, and the checker now says so instead of trusting the asterisk.

What the checker does not do: it does not send the request or replay credentials, does not judge header-value restrictions (an Authorization scheme, a Content-Type value), and does not cover redirects, null origins, Access-Control-Expose-Headers, Max-Age or Vary.

Recent tools: