Why an API Works in Postman or curl but Fails in a Browser
By Ankit Jain · Updated
Compare server connectivity with browser CORS permission, preflight, headers, redirects and cookie rules.
A successful request in a server-side client shows that the API can respond to that client. It does not show that your frontend origin has permission to read the response in a browser.
Compare the actual requests
Check the endpoint URL, method, Authorization, Content-Type, and cookies. The browser adds Origin and may send OPTIONS first. A different token, a different URL after a redirect, or a missing browser cookie can produce a different response entirely.
Native Postman and curl do not enforce the browser’s same-origin response-access checks. Browser-hosted clients depend on their execution path: a request made directly by a webpage can encounter CORS; one routed through an agent or server behaves differently.
A 200 can still be unreadable
HTTP/1.1 200 OK
Content-Type: application/json
{"message":"hello"}A browser frontend on another origin cannot read this through ordinary CORS fetch without valid origin permission. The JSON body and status do not grant it.
Verify the browser path
Open DevTools in your actual frontend. If OPTIONS fails, inspect the preflight response and fix its status and permission first. If the actual response fails, inspect its origin and credentials permission. If cookies are missing, inspect eligibility and credentials mode separately.
Adding an Origin header in curl is useful for capturing the server’s policy, but curl still will not enforce it. Follow the debugging workflow rather than changing the frontend to no-cors.