GuidesDIAGNOSE

Why a request works in Postman but not in browser scripts

Postman and curl execute HTTP requests directly against target servers without enforcing the browser same-origin policy. When the same call fails in JavaScript, the browser often received the response but refused to expose it to client code. The server completed the request normally.

The browser blocks reads, not network traffic

Postman, curl, and backend servers operate outside the browser sandbox. Because these tools have no same-origin policy to enforce, they display raw response bodies regardless of CORS headers. In contrast, a browser inspects the response headers before releasing data to client JavaScript. When headers do not grant permission, the browser blocks the script from reading the body. Server logs show a successful status code during these failures because the server handled the request completely.

Lookalike failures that mimic CORS errors

Browser consoles can emit network errors that look like missing CORS headers. Before changing server configuration, check the console message against these four common mismatches.

Redirect to a different origin. If the server issues a 301 or 302 to another host, the browser treats the redirected target as a new cross-origin hop and checks its headers.
Expired or mismatched authentication. Postman collections often store static bearer tokens or omit headers that browser fetches send automatically.
Mixed content. An HTTPS page requesting an insecure HTTP resource gets blocked immediately by the browser before generating network traffic.
Content Security Policy. A connect-src directive in the document header blocks network requests to unlisted domains regardless of server CORS settings.

Check the response headers with curl

$ curl -i https://api.open-meteo.com/v1/forecast?latitude=51.92&longitude=4.48&current=temperature_2m

HTTP/2 200
content-type: application/json; charset=utf-8
access-control-allow-origin: *
# ^ browsers may read this response from any origin

Run curl with -i to examine the raw headers returned by the upstream server. If the response omits access-control-allow-origin, no browser origin may read the data. Postman displays the payload because it never looks for this header.

Fixing an API under your control

When you manage the destination server, configure it to return an Access-Control-Allow-Origin header matching your front-end origin, or use * for credential-less public endpoints. Non-simple requests trigger an HTTP OPTIONS preflight that must return allowed methods and headers with a 200 or 204 status. Never require authentication on preflights, as browsers do not attach credentials to them. See the preflight guide for preflight requirements.

Handling third-party APIs without browser support

If you do not control the upstream API, verify whether the provider documents browser support or already sends headers. Use the header checker to inspect the upstream response directly. For public data missing headers, you can prefix the target URL with https://proxy.cors.dev/ for GET and HEAD requests. The proxy operator can observe traffic routed through it, so use this option for public data only.

Good questions.

Does Postman ever enforce CORS?

No. CORS is a browser security mechanism designed to protect authenticated user sessions from cross-site scripts. Postman acts as a direct HTTP client, so it ignores the presence or absence of access control headers.

The browser sends an Origin header and Postman does not. Does that matter?

Yes. Some servers check for the Origin header and omit CORS headers or return an error if the origin is unrecognized. You can add an Origin header in Postman to replicate the exact browser request headers.

Why does it work in an incognito window but not my app?

Incognito windows do not bypass CORS rules. If a request succeeds in incognito, your standard session likely suffered from stale service worker caches, conflicting browser extensions, or invalid session cookies sent with the request.

Keep going