How is this different from checking CORS in browser DevTools?

This tool runs a controlled preflight OPTIONS request and a follow-up actual request, then evaluates Access-Control headers with explicit pass/fail rules. It surfaces method, header, and credential mismatches in one readable report.

Why can a request still fail when Access-Control-Allow-Origin is *?

Wildcard origin works only for non-credentialed requests. If cookies or auth credentials are involved, the server must return a specific origin value and Access-Control-Allow-Credentials: true, otherwise browsers block the response.

Do you provide actionable server-side fixes when checks fail?

Yes. Each failed check includes practical fix snippets for nginx add_header config, Express cors middleware, Spring @CrossOrigin settings, plus raw header lines you can apply in other stacks or reverse proxies.

Why can preflight pass but the browser still block the actual call?

Because browsers validate CORS headers on both responses. You might allow methods/headers in OPTIONS but forget Access-Control-Allow-Origin or credentials on the actual response path, which still causes the browser to reject response access.

Do I need to include every custom request header in Allow-Headers?

Yes for preflighted requests. If your frontend sends headers such as authorization, x-request-id, or custom tracing values, each must be explicitly allowed (or covered by wildcard policy where appropriate) or the browser will block the call.

What is the safest pattern for credentialed cross-origin APIs?

Return an explicit origin value (never *) plus Access-Control-Allow-Credentials: true, ensure cookies are configured correctly, and include Vary: Origin. This keeps policy strict while still enabling authenticated browser requests.

CORS Tester / Preflight Checker

Send real OPTIONS + actual probes from a guarded server route, then get pass/fail checks with fix hints for nginx, Express, Spring, and raw headers.

Updated June 2026

CORS preflight input

Target endpoint URLOrigin to test

MethodRequest headers (comma-separated)

Include credentials (cookies/auth)

How to use CORS Tester / Preflight Checker

CORS Tester / Preflight Checker runs a true server-side preflight and follow-up request so you can diagnose cross-origin policy errors with clear evidence instead of guesswork. Enter endpoint URL, intended browser origin, method, requested headers, and credential mode; the tool sends OPTIONS + actual probes, keeps only relevant CORS headers, and evaluates pass/fail checks for origin match, allowed methods, header coverage, and credentials. Failed checks include concrete remediation snippets for nginx, Express, Spring, and raw headers, making it easier to move from browser error messages to actionable server fixes quickly.

Enter the target endpoint URL and the exact origin your frontend uses, then choose the intended HTTP method.
List any custom request headers (for example authorization or x-request-id) and toggle credentials if cookies/auth are needed.
Run the check to execute OPTIONS preflight and the actual request from the server-side probe route.
Review verdict rows for origin, methods, headers, and credentials, then expand failed checks for stack-specific fixes.
Open raw preflight and actual header tables to confirm final Access-Control values after proxies/CDNs.

Common CORS errors decoded

“No Access-Control-Allow-Origin header” usually means the server never emitted ACAO for that route, while “CORS policy: credential is not supported if ACAO is *” means wildcard origin conflicts with cookies/auth requirements. “Request header field X is not allowed by Access-Control-Allow-Headers” points to incomplete allow-header lists in preflight responses. Browser console messages often collapse these scenarios into generic failures, so checking preflight status and exact header values side by side is critical. This tool decodes each condition into plain-English outcomes and ties them to targeted fix guidance, reducing time spent guessing across middleware, reverse proxies, and application frameworks.

Why preflight and actual responses must both be correct

A successful OPTIONS preflight alone does not guarantee browser success. Browsers still validate CORS headers on the actual response, including Access-Control-Allow-Origin and Access-Control-Allow-Credentials when needed. In production stacks, preflight might be handled by one layer (edge proxy) while actual responses come from another (application service), creating mismatches that only appear at runtime. Reliable diagnostics therefore require observing both responses as a pair: methods and request headers must be allowed during preflight, and origin/credentials must remain valid on the final response. By capturing both stages, teams can isolate whether failures come from policy logic, route-specific config, or upstream infrastructure overrides.

Operational hardening: Vary and max-age considerations

Two often-overlooked headers affect CORS behavior at scale. Vary: Origin helps caches avoid serving one origin’s CORS response to a different origin by mistake, which can cause inconsistent browser failures across regions. Access-Control-Max-Age controls how long preflight results are cached client-side; too low increases latency, too high can delay rollout of policy changes if mistakes are cached. While these headers do not decide basic allow/deny alone, they strongly influence reliability and performance in real deployments with CDNs and shared caches. Treat them as operational tuning knobs after core policy checks pass.

Worked examples

Wildcard + credentials mismatch

Inputs: Origin app.example, credentials ON, ACAO=*

Result: Fail verdict explains wildcard cannot be used with credentials

Missing allow-header issue

Inputs: Requested header authorization not in ACAH

Result: Fail row flags missing header and provides fix snippets

Healthy credentialed setup

Inputs: Exact origin, PUT allowed, ACAH list complete

Result: Overall pass with info rows for max-age and expose-headers

Glossary

Preflight request: An OPTIONS request browsers send before certain cross-origin requests to confirm policy permissions.
Access-Control-Allow-Origin: Response header declaring which origin may read the cross-origin response in browser JavaScript.
Access-Control-Allow-Headers: Preflight response header listing non-safelisted request headers permitted for actual requests.
Credentialed request: A browser request that includes cookies or authenticated context and requires stricter CORS rules.
Vary: Origin: Caching hint indicating responses differ by Origin header, preventing incorrect cache reuse across origins.

Frequently Asked Questions

Free · No spam

Get weekly tool tips & updates

New tools, power-user tips, and productivity hacks — delivered free every Friday.

No spam, ever. Unsubscribe with one click.

Why use CORS Tester / Preflight Checker?

Executes real preflight and actual probes against the target endpoint with guarded SSRF protections
Evaluates CORS policy with explicit pass/fail checks for origin, methods, headers, and credentials
Highlights wildcard-with-credentials misconfigurations and missing allow-header coverage immediately
Provides ready-to-apply remediation snippets for nginx, Express middleware, Spring annotations, and raw headers

Common use cases

Diagnose browser CORS failures where network traces are hard to interpret across environments
Validate cross-origin API readiness before launching a frontend on a new domain or subdomain
Confirm credentialed flows (cookies/session auth) include strict origin and allow-credentials headers
Document CORS gaps with reproducible evidence and fix snippets for handoff to backend or platform teams

Related Developer Tools

API Tester (Online REST Client)

Build and send HTTP requests with method, URL, headers, auth, and JSON body, then inspect status, timing, headers, and response payload in one browser tool.

HTTP Headers Checker

View HTTP response headers for any URL. Check status codes, security headers, caching, redirects, and server details instantly. Free and private.

HTTP Debug & Test Endpoints

Test real HTTP clients against permanent debug endpoints for status codes, echo payloads, redirects, headers, gzip, and SSE from one base URL.

JSON Formatter & Validator

Format, validate, and minify JSON instantly. Includes syntax highlighting, error detection, and a collapsible tree view — free, private, in-browser.

Regex Tester

Test and debug regular expressions online. See live matches, capture groups, and replace output. Free, private, instant.

Base64 Encoder & Decoder

Encode text or files to Base64, or decode Base64 strings back to text. Fast, free, and runs entirely in your browser.

Explore all Developer Tools.