AIStacker
Web

Overview

CORS Header Checker

Check whether a browser request will pass CORS based on the request method, custom headers, credentials mode, and the response headers your API returns.

What isHow to useExampleCommon use casesFrequently asked questions

Category hub

Web

Problems

5

FAQ

3

Quick links

Browse hub
#access-control-allow-origin-checker#cors-allow-methods-validation#cross-origin-header-inspector#cors-allow-headers-checker#api-cors-error-tool
Browser-side CORS triage

CORS Header Checker

Check whether a browser request will pass CORS based on the request method, custom headers, credentials mode, and the response headers your API currently returns.

Request context

Response headers

Verdict

Blocked by browser CORS policy

Preflight
Required
Requested headers
2
Allowed methods
3
Browser reasoning
Wildcard origin cannot be used with credentials

Browsers reject credentialed requests when Access-Control-Allow-Origin is '*' . Reflect the exact origin instead.

This request triggers a browser preflight

A browser will send OPTIONS first because the method or headers are outside the simple-request rules.

Credentials mode raises the CORS bar

If your frontend sends cookies or auth-bearing credentialed requests, the response headers must be much stricter than the public '*' pattern.

What usually fixes the mismatch
  • Reflect the exact frontend origin instead of returning * when credentials are involved.
  • Make sure the preflight response explicitly allows the real method and every custom request header the browser asked for.
  • Debug the browser request as two steps: preflight first, actual response second. Many teams only inspect the final API handler.

What you can solve

Why does my API work in Postman but fail in the browser with a CORS error?

The browser enforces CORS before exposing the response to JavaScript, while Postman and curl do not. That means the HTTP response can be technically valid, but still unusable in the browser because the returned CORS headers do not match the request origin, method, custom headers, or credentials mode.

Why does Access-Control-Allow-Origin star fail with credentials?

Credentialed browser requests require a stricter CORS contract than public anonymous requests. If the frontend sends cookies or other credentialed state, the browser will reject `Access-Control-Allow-Origin: *` and expect a concrete allowed origin instead.

How do I know which header is actually breaking my preflight request?

Compare the headers the browser wants to send against `Access-Control-Allow-Headers` one by one. The failure is often caused by a single missing custom header such as `authorization`, `x-api-key`, or a JSON content-type that was never explicitly allowed.

What happens if the browser wants to send PATCH or DELETE but Allow-Methods does not include it?

The browser stops at the preflight stage and never sends the real request. This is why method mismatches often look like the backend route is broken even though the route handler never receives the request at all.

Why can CORS work locally and fail in production with the same frontend code?

Production often introduces an extra proxy, CDN, auth layer, or ingress rule that rewrites or strips the headers your local server returned directly. The frontend code may be identical while the effective CORS headers seen by the browser are no longer the same.

Typical workflow

HTTP Status Code ExplorerURL Query Parameter InspectorCORS Header CheckerJSON Validator – Check JSON Syntax & Find ErrorsJWT Decoder

Guides for this workflow

Supporting guides that connect this tool to the broader category workflow.

Open category hub
Web guide

Why Access-Control-Allow-Origin Star Fails with Credentials

A practical browser-first guide to diagnosing the most common credentialed CORS mistake: returning wildcard Allow-Origin while the frontend sends cookies or auth-bound credentials.

Web guide

Why Set-Cookie Fails Even When the Response Looks Correct

A debugging guide for separating browser cookie policy rejections from backend response success when auth cookies appear to vanish after login.

Web guide

400 vs 401 vs 403 vs 422: A Practical API Error Triage Workflow

A concrete debugging workflow for separating malformed requests, authentication failures, permission issues, and validation errors before your team fixes the wrong thing.

Web guide

encodeURI vs encodeURIComponent for redirect_uri and Query Params

A practical guide to choosing the right encoding boundary for redirect_uri, nested URLs, and query parameter values before a small encoding mistake turns into a redirect bug.

What is

What is CORS Header Checker?

A CORS Header Checker helps you answer the question that usually matters most in browser debugging: will the browser allow this request to proceed, or will it stop at the policy layer first? Instead of reading CORS headers one by one and guessing, you can compare the request method, custom headers, credentials mode, and response headers in one place.

This is especially useful when an API works in Postman or curl but fails in the browser. In that situation, the backend may be fine at the transport layer while the browser still blocks the response because the CORS contract is incomplete or internally inconsistent.

How to use

How to use CORS Header Checker

Enter the frontend origin, request method, and any custom request headers the browser will send. Then fill in the response headers your API or gateway currently returns, especially `Access-Control-Allow-Origin`, `Access-Control-Allow-Methods`, and `Access-Control-Allow-Headers`.

The checker will tell you whether the browser sees the request as simple or preflighted, whether the origin is allowed, and whether the preflight response actually grants the method and headers you are asking for.

Example

Example

Scenario:
Frontend origin: https://app.aistacker.dev
Method: GET
Headers: authorization, x-client-version
Allow-Origin: *
Allow-Methods: GET, POST, OPTIONS
Allow-Headers: authorization, x-client-version
Credentials: true

Result:
The browser blocks the request because wildcard Allow-Origin cannot be combined with credentialed requests. Reflect the exact origin instead.

Common use cases

Common use cases

1. Explaining why an API call succeeds in curl but fails in the browser.

2. Checking whether a custom header is the real reason a preflight fails.

3. Verifying whether `Access-Control-Allow-Origin: *` is safe for the request mode you are using.

4. Comparing local success against production failure when a gateway rewrites or strips CORS headers.

Frequently asked questions

Frequently asked questions

Why can a request work in Postman but fail in the browser?v
Postman and curl are not bound by the browser's CORS enforcement model. The server may respond successfully at the HTTP level, while the browser still blocks the response because the returned CORS headers do not satisfy the browser policy for that request.
Does every cross-origin request trigger a preflight?v
No. Simple requests using safe methods and simple headers can skip preflight. As soon as you introduce custom headers, JSON content types, or non-simple methods such as PUT or PATCH, the browser is much more likely to send an OPTIONS preflight first.
Why does wildcard Allow-Origin break when credentials are enabled?v
Browsers reject credentialed CORS responses when `Access-Control-Allow-Origin` is `*`. Once credentials are involved, the response must usually reflect a specific allowed origin instead of using the wildcard pattern.