Postman vs browser: the real difference

The first mistake beginners make is assuming Postman and browser fetch are the same kind of client. They are not. Postman is an API testing tool. cURL is a command-line HTTP client. They can send a request directly to the API and show the response. A browser page running JavaScript has to obey browser security rules because it is executing code from a website origin.

An origin is not just the domain name. It includes the scheme, hostname, and port. These are different origins:

https://example.com
http://example.com
https://api.example.com
https://example.com:3000
http://localhost:3000
http://localhost:5173

So when your React app runs at http://localhost:5173 and calls https://api.example.com, the browser sees that as a cross-origin request. The API server must explicitly allow that browser origin to read the response. If it does not, Postman may still work while the browser fails.

The useful question is not only, “Does the API work?” The better question is, “Does this API allow this browser origin, with this method, with these headers, with this body type, with these credentials, over this protocol?”

CORS is not the API failing. It is the browser refusing access.

CORS means Cross-Origin Resource Sharing. It is a browser security mechanism that decides whether JavaScript running on one origin can access a response from another origin. The important part is this: CORS is controlled by server response headers, not by wishful thinking in frontend code.

A common beginner error looks like this:

Access to fetch at 'https://api.example.com/users'
from origin 'http://localhost:5173' has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.

This does not always mean the URL is wrong. It means the browser made, or tried to make, a cross-origin request and did not receive the permission header it needed. The API may still work in Postman because Postman is not running inside your website origin.

The server response must allow the browser origin

For a simple public API response without cookies, the server may respond like this:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://localhost:5173
Content-Type: application/json

For public, non-credentialed resources, some APIs use a wildcard:

Access-Control-Allow-Origin: *

But wildcard CORS is not a safe default for private dashboards, student admin panels, paid APIs, cookie-based sessions, or any API that returns user-specific data. If cookies or credentials are involved, the server usually needs to return a specific origin, not *.

Preflight: the hidden OPTIONS request beginners miss

Many “works in Postman but fails in browser” issues happen before the real request. The browser sends a preflight request first. This is an OPTIONS request that asks the server if the real request is allowed.

For example, your frontend wants to send this:

POST /v1/orders
Authorization: Bearer YOUR_TOKEN
Content-Type: application/json

Before sending the real POST, the browser may send something like this:

OPTIONS /v1/orders HTTP/1.1
Origin: http://localhost:5173
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

The server must answer the preflight with headers that allow the requested origin, method, and headers:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600

If the server rejects OPTIONS, redirects it to login, requires authentication on it, returns a 404, returns a 405, or forgets to include the requested headers, the browser may never send your real POST. This is why your backend logs can look empty even though your frontend code “made a request.” The browser stopped at the permission check.

Common preflight failures

Authorization and Content-Type can change browser behavior

Two headers show up again and again in this problem: Authorization and Content-Type. They are normal API headers, but they can also cause the browser to use preflight for cross-origin requests.

Authorization header mistakes

In Postman, you may use the Authorization tab and it quietly formats the token correctly. In browser code, you must build the header yourself. A tiny mismatch can cause a 401, 403, or a preflight failure.

Good fetch example:

const response = await fetch("https://api.example.com/v1/profile", {
  method: "GET",
  headers: {
    "Authorization": "Bearer YOUR_TOKEN",
    "Accept": "application/json"
  }
});

Common mistakes:

• Using BearerYOUR_TOKEN without the space.
• Forgetting the word Bearer when the API expects it.
• Using a staging token against production.
• Copying a token with a hidden newline or extra space.
• Sending the token in the browser when the API key should stay server-side.
• Preflight failing because the server forgot Authorization in Access-Control-Allow-Headers.

If the browser sends this preflight:

Access-Control-Request-Headers: authorization

Then the API should allow it in the preflight response:

Access-Control-Allow-Headers: Authorization

Content-Type mistakes

Postman can send JSON correctly because you selected “raw JSON” or used its body editor. In browser code, you need both the right header and the right body serialization.

Correct JSON request:

const response = await fetch("https://api.example.com/v1/orders", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "Accept": "application/json"
  },
  body: JSON.stringify({
    productId: 42,
    quantity: 1
  })
});

Wrong version that often creates confusing backend errors:

const response = await fetch("https://api.example.com/v1/orders", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: {
    productId: 42,
    quantity: 1
  }
});

That bad version does not send the object as JSON. It sends the wrong thing because the object was not stringified. Depending on the backend, you might see a 400, 415, 422, empty body, or validation error.

Cookies, sessions, and credentials are a separate layer

Some APIs do not use bearer tokens. They use login cookies or server sessions. This can become confusing because Postman may store cookies differently from your browser, and browser fetch does not always send cookies the way beginners expect.

For fetch, credential behavior matters:

const response = await fetch("https://api.example.com/account", {
  method: "GET",
  credentials: "include"
});

But credentials: "include" is only one side of the problem. The server must also allow credentialed cross-origin access. A typical credentialed CORS response needs a specific origin and credentials permission:

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

Do not combine credentialed requests with this:

Access-Control-Allow-Origin: *

That wildcard pattern is a common reason a browser blocks a response even though the request appears to work elsewhere.

Cookie settings to check

• Domain: Is the cookie valid for the frontend and API domain relationship you are using?
• SameSite: Cross-site cookie behavior depends on this setting.
• Secure: Cookies meant for cross-site HTTPS flows often need secure transport.
• Credentials option: Browser fetch needs the correct credentials value.
• CORS response: Credentialed responses need the correct server-side CORS headers.
• Third-party cookie restrictions: Browser privacy settings can affect third-party cookies.

If Postman succeeds because it has a cookie but your browser fails because the cookie is not sent, this is not a JSON problem. It is a credential transport problem.

HTTPS, mixed content, and redirects can break browser requests

A browser page loaded over HTTPS should not casually call insecure HTTP APIs. If your site is secure but the API URL starts with http://, the browser may block the request as mixed content or upgrade/block parts of the request depending on resource type and browser behavior.

This can happen when:

• Your local API runs on http://localhost:8000 but your deployed frontend runs on HTTPS.
• Your API documentation shows an old http:// endpoint.
• The API redirects from HTTP to HTTPS and the preflight does not survive the redirect cleanly.
• A WordPress site uses HTTPS but a custom script calls an HTTP API URL.

Use the final HTTPS endpoint directly when testing from the browser:

https://api.example.com/v1/orders

Instead of relying on this redirect chain:

http://api.example.com/v1/orders
301 redirect to https://api.example.com/v1/orders

The practical debugging order

When beginners debug this issue randomly, they waste hours changing headers, rewriting fetch code, reinstalling packages, switching Axios to fetch, or blaming React. Use this order instead.

Working cURL vs browser fetch example

Suppose this cURL request works:

curl -i -X POST "https://api.example.com/v1/orders" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  --data '{"productId":42,"quantity":1}'

A matching browser fetch request would look like this:

async function createOrder() {
  const response = await fetch("https://api.example.com/v1/orders", {
    method: "POST",
    headers: {
      "Authorization": "Bearer YOUR_TOKEN",
      "Content-Type": "application/json",
      "Accept": "application/json"
    },
    body: JSON.stringify({
      productId: 42,
      quantity: 1
    })
  });

  const data = await response.json();

  if (!response.ok) {
    console.error("API error:", response.status, data);
    return;
  }

  console.log("Order created:", data);
}

But this browser version can still fail even if the cURL works. Why? Because the browser may first ask the API this question:

Can http://localhost:5173 send a POST request to /v1/orders
with Authorization and Content-Type headers?

The server must answer yes with CORS headers. If it does not, the browser blocks the flow before the JavaScript gets a readable API response.

Server headers needed for this example

Access-Control-Allow-Origin: http://localhost:5173
Access-Control-Allow-Methods: POST, OPTIONS
Access-Control-Allow-Headers: Authorization, Content-Type, Accept

For production, do not leave your local origin hardcoded. You may need to allow your real frontend domain:

Access-Control-Allow-Origin: https://yourfrontenddomain.com

Bad fixes that hide the real problem

When developers search this error online, they often find shortcuts that seem to make the console message disappear. Many of those shortcuts are not real fixes.

Special note for WordPress users

This problem also appears in WordPress. A Custom HTML block, theme script, shortcode, plugin snippet, or page builder widget may call an API from the visitor’s browser. If that API does not allow your WordPress site origin, the request can fail even though it works in Postman.

For public APIs with browser support, frontend JavaScript may be fine. For private keys, paid APIs, admin APIs, or APIs that need secret credentials, use server-side WordPress code instead. That usually means calling the API with wp_remote_get(), wp_remote_post(), or wp_remote_request() from PHP rather than exposing the key in browser JavaScript.

Example WordPress-style server-side request:

$response = wp_remote_post('https://api.example.com/v1/orders', array(
  'headers' => array(
    'Authorization' => 'Bearer YOUR_SERVER_SIDE_TOKEN',
    'Content-Type'  => 'application/json',
    'Accept'        => 'application/json',
  ),
  'body' => wp_json_encode(array(
    'productId' => 42,
    'quantity'  => 1,
  )),
  'timeout' => 20,
));

Notice that the token belongs on the server side in this example. If you paste a secret token into public page JavaScript, visitors may be able to find it.

Common browser errors and what they usually mean

Copyable debugging note template

Before asking for help, collect the real clues. A clear note saves time because it separates “the API is broken” from “the browser blocked the request before the API route ran.”

API browser debugging note

Frontend origin:
Example: http://localhost:5173

API URL:
Example: https://api.example.com/v1/orders

Method:
POST

Works in Postman or cURL?
Yes / No

Browser error message:
Paste exact console error here.

Network tab:
- Is there an OPTIONS request? Yes / No
- OPTIONS status code:
- Actual request status code:
- Did the real request get sent? Yes / No

Request headers I am trying to send:
Authorization
Content-Type
Accept

Request body type:
JSON / FormData / query string / no body

Auth type:
Bearer token / cookie session / API key / none

CORS response headers received:
Access-Control-Allow-Origin:
Access-Control-Allow-Methods:
Access-Control-Allow-Headers:
Access-Control-Allow-Credentials:

What changed recently:
New domain / local to production / new token / backend update / HTTPS change / plugin change

Related CodeZips tools for this problem

Use these tools when you want to turn the debugging process into a clearer checklist, request comparison, or support note.

Technical references used for this guide

This article is written as a practical beginner debugging workflow, but the browser behavior is based on standard web platform documentation.

• MDN Web Docs: Cross-Origin Resource Sharing
• MDN Web Docs: Using the Fetch API
• MDN Web Docs: Access-Control-Allow-Headers
• MDN Web Docs: Mixed content
• Google Search Central: Creating helpful, reliable, people-first content