Works in Postman, Fails in the Browser: Where to Start Debugging

Poonam Biradar — Thu, 22 Oct 2026 09:36:41 +0000

An API returns 200 OK in Postman, but the frontend can’t load the data.

Where do you start?

CORS is one possibility. But before changing server settings, check whether your frontend is sending the same request you tested in Postman.

Here are three checks that help narrow it down.

1. Compare what you actually sent

Consider this example.

In Postman, you configure bearer authentication and successfully request a list of orders:

GET https://api.example.com/api/orders
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/json

Then you write this in your frontend:

const response = await fetch(
  "https://api.example.com/api/orders"
);

Same endpoint. Different request.

The frontend isn’t sending the authorization header. Postman’s saved token doesn’t carry over to your application.

For an API that requires bearer authentication, the request could look like this:

async function getOrders(accessToken) {
  const response = await fetch(
    "https://api.example.com/api/orders",
    {
      headers: {
        Accept: "application/json",
        Authorization: `Bearer ${accessToken}`,
      },
    }
  );

  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }

  return response.json();
}

The URL above is a placeholder. Use your endpoint and a valid user access token from your authentication flow.

Also compare the method, query parameters, and request body. If the token is present, check whether it has expired.

Notice the response.ok check: fetch() doesn’t automatically throw when the server returns an HTTP error such as 401.

2. Read the browser’s request

Instead of relying only on an error message in the UI, open:

Developer Tools → Network

Trigger the request again and select it.

Start with four questions:

Is this the URL I expected?
Did the authorization header get sent?
What status came back?
What does the response body say?

For example, a readable 401 response gives you a reason to investigate authentication. An HTML response where you expected JSON might be a login page or an error page.

Check the Console too. If it reports a CORS error, move to the next check.

3. Check whether the browser can read the response

Suppose your application uses these addresses:

Frontend: http://localhost:3000
API:      http://localhost:8000

They have different ports, so they are different origins.

For browser-side JavaScript to read that API response, the server needs to allow the frontend’s origin through CORS.

Postman’s desktop client doesn’t enforce the browser’s same-origin restrictions. A successful request there doesn’t confirm that browser access is configured.

For this local setup, the server might return:

Access-Control-Allow-Origin: http://localhost:3000

This is a response header set by the server. Adding it to your frontend request won’t grant permission.

And a CORS error doesn’t always mean the API received nothing. The server may have responded while the browser prevented your JavaScript from reading the response.

What about the OPTIONS request?

A cross-origin request containing an Authorization header generally triggers a preflight.

You’ll see an OPTIONS request in the Network tab before the intended request. The browser uses it to check whether the method and headers are allowed.

If that check fails, the intended request won’t be sent.

Check your server’s CORS settings and whether middleware or a proxy is rejecting OPTIONS. The actual response needs the appropriate CORS headers too.

Avoid treating this as a fix:

fetch(url, { mode: "no-cors" });

For a normal JSON API integration, it leaves you with a response your JavaScript cannot read normally.

One distinction if you use Next.js

These browser restrictions apply when the request runs in the browser.

A request from a Next.js server route runs on the server, where browser CORS enforcement doesn’t apply. Authentication, network access, and the API’s own restrictions still matter.

So check where the request executes, not just which framework you’re using.

Where I’d start

Before changing the backend, compare the working Postman request with the request shown in the browser’s Network tab.

That comparison helps separate three different problems:

The frontend sent something different.
The API rejected the request.
The browser wouldn’t let JavaScript read the response.

Each needs a different fix.

If you’ve run into this mismatch, what turned out to be different?

DEV Community: Poonam Biradar