Menu

Pages

Tools

React CORS Debugging JavaScript March 2026 ⏱ 13 min read

How to Fix CORS Error in React Localhost: Complete Guide

Understand exactly what the CORS error in React means, why Postman works but your browser does not, and all three ways to fix it: Express backend configuration, React proxy, Vite proxy, and production CORS setup.

It is 10:47pm. Your React app is talking to a Node.js backend and everything works perfectly when you test with Postman. You make the same request from React and you get a wall of red text in the browser console. You search Stack Overflow. The first answer tells you to add a header. The second contradicts it. The third works but breaks something else. An hour later you are more confused than when you started. This guide is what I wish I had that night.

Jump to a section
The actual CORS error What is CORS? Why Postman works but React doesn’t What is an origin? Method 1: Fix the backend Express, Flask, Django Method 2: React / Vite proxy Method 3: External API proxy Error variants decoded CORS in production 7-step debug guide FAQ

The CORS Error in React Localhost

Here is the exact error that sends developers into a Stack Overflow spiral. You have seen this if you are reading this page:

Browser Console Error
Access to fetch at ‘http://localhost:5000/api/users’ from origin ‘http://localhost:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

Or this variant when you try to send authentication headers:

Browser Console Error
Access to fetch at ‘http://localhost:5000/api/users’ from origin ‘http://localhost:3000’ has been blocked by CORS policy: The value of the ‘Access-Control-Allow-Origin’ header in the response must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’.

Both errors have a fix. But before you paste the fix into your code, understanding what actually caused this saves you a lot of grief later, especially when you hit the second or third variant.

What Is CORS and Why Does the Browser Block the Request?

CORS stands for Cross-Origin Resource Sharing. It is a security feature built into every web browser that restricts JavaScript from making requests to a different origin than the page it is running on. It exists to protect you as a user. Without CORS, any malicious website could make requests to your bank on your behalf, using your browser’s stored cookies and authentication.

The security model works like this: when your JavaScript code in a browser makes a fetch request to a different origin, the browser checks whether the server at that origin has explicitly permitted requests from your page’s origin. It does this by looking for specific HTTP response headers. If those headers are missing or do not include your origin, the browser blocks the response from reaching your JavaScript code. The request still went to the server. The server still responded. The browser intercepted the response and threw it away.

CORS is enforced by the browser, not the server. Your backend is working perfectly. Your request is reaching the server. The browser is the one blocking the response. That is why Postman works and your React app does not.

Why Postman Works But React Gets Blocked

This is the most confusing part for developers encountering CORS for the first time. You test your API in Postman. It works. You hit the same endpoint from React. CORS error. Is the backend broken? No. Is your fetch code wrong? No. So what is happening?

Postman is not a browser. It does not have a security origin. It does not enforce CORS. When Postman sends a request, it goes directly to your server, gets the response, and shows it to you with no filtering. When your React app sends the same request, the browser checks the response headers, finds no permission to share the response with your React code’s origin, and blocks it.

Your backend is healthy. Your request code is correct. The CORS error is the browser doing its job. The fix is telling the browser that your backend intends to allow requests from your React app’s origin, which you do by adding the right headers to your backend’s responses.

What Counts as a Different Origin?

An origin is the combination of three things: protocol, domain, and port. Two URLs are the same origin only if all three parts match exactly. If any one differs, they are different origins and CORS applies.

React Dev Server
http://localhost:3000
Protocol: http
Domain: localhost
Port: 3000
Different origin from backend
Node.js / Express Backend
http://localhost:5000
Protocol: http
Domain: localhost
Port: 5000
Port 5000 ≠ Port 3000

Same computer. Same localhost hostname. But different ports. The browser treats them as completely separate origins and the CORS check applies. This surprises almost everyone the first time. You might reasonably assume localhost is localhost. The browser disagrees.

The same rule applies in production. Your React app at https://app.yourdomain.com and your API at https://api.yourdomain.com are different origins even though they share the same root domain. Subdomain differences count as different origins under the browser’s security model.

Method 1
Fix CORS on the Backend (The Right Solution)
Configure your server to send the correct Access-Control-Allow-Origin headers

This is the correct fix in almost every situation. The backend sends response headers that tell the browser which origins are allowed to read the response. Once the browser sees your React app’s origin in those headers, it stops blocking. This fix works in development and in production, and it is the only fix that scales correctly.

Here is how to add CORS support for the three most common backend frameworks:

Node.js / Express
bash
npm install cors
Express — CORS middleware setup
const express = require(‘express’); const cors = require(‘cors’); const app = express(); // Option A: Allow any origin (development only) // Never use this in production with credentials app.use(cors()); // Option B: Allow your React app’s specific origin (recommended) app.use(cors({ origin: ‘http://localhost:3000’, methods: [‘GET’, ‘POST’, ‘PUT’, ‘DELETE’, ‘OPTIONS’], allowedHeaders: [‘Content-Type’, ‘Authorization’], credentials: true // Required if you send cookies or auth headers })); // CORS middleware must come BEFORE your route definitions app.get(‘/api/users’, (req, res) => { res.json({ users: [] }); });
Python / Flask
bash
pip install flask-cors
Flask — CORS configuration
from flask import Flask from flask_cors import CORS app = Flask(__name__) # Allow only your React app’s origin (recommended) CORS(app, origins=[‘http://localhost:3000’], supports_credentials=True) # Or allow all origins during development (not for production with auth) CORS(app) @app.route(‘/api/users’) def get_users(): return {‘users’: []}
Python / Django
bash
pip install django-cors-headers
Django — settings.py
INSTALLED_APPS = [ ‘corsheaders’, # Add this ‘django.contrib.contenttypes’, # … rest of your apps ] MIDDLEWARE = [ ‘corsheaders.middleware.CorsMiddleware’, # Must be FIRST ‘django.middleware.common.CommonMiddleware’, # … rest of your middleware ] # Allow only your React app’s origin CORS_ALLOWED_ORIGINS = [ ‘http://localhost:3000’, ] # Required if your React app sends cookies or Authorization headers CORS_ALLOW_CREDENTIALS = True # For development only (never in production with authentication) # CORS_ALLOW_ALL_ORIGINS = True
⚠ Place CORS middleware before all route handlers

In Express, this catches many developers: the app.use(cors()) call must come before any route definitions. If you place it after your routes, the routes handle the request before CORS headers are added and the browser gets a response with no CORS headers. In Django, CorsMiddleware must be the first item in the MIDDLEWARE list for the same reason.

Method 2
Use a Proxy in React Dev Server
Route API requests through the React development server so CORS never applies

If you cannot or do not want to modify the backend, the React development server can act as a proxy. When your React code calls /api/users, the dev server forwards that request to your backend at http://localhost:5000/api/users. Because the request comes from the dev server rather than the browser, CORS does not apply. The browser sees the response as coming from the same origin as the React app, so it allows it through.

This proxy works in development only. It has no effect on a production build. For production, you need the backend CORS headers from Method 1, or you need to serve both the frontend and backend from the same origin.

Create React App

Add one line to your package.json:

package.json
{ “name”: “my-react-app”, “version”: “1.0.0”, “proxy”: “http://localhost:5000”, “scripts”: { … } }

Then change your fetch calls to use relative paths instead of the full URL:

React — fetch with proxy
// Before: full URL causes CORS error const response = await fetch(‘http://localhost:5000/api/users’); // After: relative path goes through proxy, no CORS error const response = await fetch(‘/api/users’);

Restart your React dev server after adding the proxy. The dev server does not pick up package.json changes automatically.

Vite

Vite uses a configuration file instead of package.json for proxy settings:

vite.config.js
import { defineConfig } from ‘vite’; import react from ‘@vitejs/plugin-react’; export default defineConfig({ plugins: [react()], server: { proxy: { // Any request starting with /api gets forwarded to localhost:5000 ‘/api’: { target: ‘http://localhost:5000’, changeOrigin: true, // rewrite: (path) => path.replace(/^\/api/, ”) // Remove /api prefix if backend doesn’t use it }, // You can add multiple proxy rules for different services ‘/auth’: { target: ‘http://localhost:5001’, changeOrigin: true, } } } });
✅ Vite proxy supports multiple backend services

One thing Vite handles better than Create React App is proxying to multiple different backend services. If your React app talks to a main API on port 5000, an authentication service on port 5001, and a file service on port 5002, you can proxy each path prefix to a different backend target. This is handy for microservices setups during development.

Method 3
Use a CORS Proxy for External APIs
For third-party APIs that do not support CORS and that you cannot control

Sometimes you are calling a third-party API that simply does not send CORS headers. Maybe it is an older API designed for server-to-server use, or the API provider just never added browser support. In development, you can route the request through a CORS proxy service that adds the necessary headers.

JavaScript — development-only CORS proxy
// Development only. Never use a public CORS proxy in production. const API_URL = ‘https://api.external-service.com/data’; const PROXY_URL = ‘https://cors-anywhere.herokuapp.com/’; const response = await fetch(PROXY_URL + API_URL); const data = await response.json();
🚨 Never use a public CORS proxy in production

Public CORS proxy services like cors-anywhere are for development and quick testing only. In production, your requests would pass through a third party’s server: they can see your API keys, your request data, and your users’ data. They can also go down at any time, taking your app with them. The production solution is to route the request through your own backend, which makes the request server-to-server where CORS does not apply. Your backend acts as the middleman and forwards the response to your frontend.

Express — your own backend as a proxy for external APIs
// Your Express backend proxies requests to the external API // Your React app calls YOUR backend, not the external API directly app.get(‘/api/external-data’, async (req, res) => { try { const response = await fetch( ‘https://api.external-service.com/data’, { headers: { ‘Authorization’: `Bearer ${process.env.EXTERNAL_API_KEY}` } } ); const data = await response.json(); res.json(data); } catch (error) { res.status(500).json({ error: error.message }); } });

The CORS Error Variants Decoded

The CORS error comes in several flavours, each pointing to a different specific problem. Reading the exact error message saves a lot of time:

Variant 1: Missing header entirely
No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
The backend is not sending any CORS headers at all. The cors middleware is either not installed, not imported, or placed after your route handlers.
Add npm install cors and app.use(cors()) before all routes. Restart the server.
Variant 2: Wildcard origin with credentials
The value of ‘Access-Control-Allow-Origin’ header must not be the wildcard ‘*’ when the request’s credentials mode is ‘include’.
Your backend is using origin: ‘*’ (wildcard) but your React fetch call includes credentials: ‘include’. Browsers forbid this combination because it would allow any website to make authenticated requests.
Change origin: ‘*’ to origin: ‘http://localhost:3000’ in your cors config. Add credentials: true to cors config. Confirm the fetch call has credentials: ‘include’.
Variant 3: Preflight request fails
Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present.
Before sending a POST, PUT, or DELETE request with custom headers, the browser sends a preliminary OPTIONS request to check permissions. Your backend is not handling this OPTIONS request or is not sending CORS headers in response to it.
Ensure the cors middleware is applied globally (not just to specific routes) and is placed before all route definitions. Make sure ‘OPTIONS’ is in the allowed methods list.
Variant 4: Works for GET but not POST
Access to fetch… has been blocked by CORS policy (on POST requests only)
Simple GET requests without custom headers do not trigger a preflight. POST requests with a JSON body (Content-Type: application/json) do trigger a preflight OPTIONS request. If your cors middleware only handles GET or is positioned after some routes, GET works but POST fails.
Move app.use(cors(…)) to the top of your Express setup, before any route definitions. Confirm your cors config includes POST and OPTIONS in the allowed methods.

The Part Nobody Covers: CORS in Production

Fixing the CORS error in React localhost development is one problem. Deploying to production and discovering the CORS error is back is another problem entirely, and it catches people who only half-understood the development fix.

In production, your React app is typically hosted at something like https://app.yourdomain.com. Your API runs at https://api.yourdomain.com. Different subdomains, different origins. The browser still enforces CORS. If your backend still has origin: ‘http://localhost:3000’ hardcoded, every request from the production frontend is blocked.

The correct approach is to use environment variables for the allowed origin so you can set the right value for each environment without changing code:

Express — environment-aware CORS configuration
// ALLOWED_ORIGINS=http://localhost:3000 in .env // ALLOWED_ORIGINS=https://app.yourdomain.com in production const allowedOrigins = process.env.ALLOWED_ORIGINS ? process.env.ALLOWED_ORIGINS.split(‘,’) : [‘http://localhost:3000’]; app.use(cors({ origin: (origin, callback) => { // Allow requests with no origin (Postman, server-to-server) if (!origin) return callback(null, true); if (allowedOrigins.includes(origin)) { callback(null, true); } else { callback(new Error(`Origin ${origin} not permitted by CORS`)); } }, credentials: true }));
Environment variables setup
# .env (development) ALLOWED_ORIGINS=http://localhost:3000 # Production environment (set in your hosting platform) ALLOWED_ORIGINS=https://app.yourdomain.com,https://www.yourdomain.com
🚨 Never use CORS_ALLOW_ALL_ORIGINS = True in production with authentication

The wildcard origin (origin: ‘*’) combined with credentials: true is both a security vulnerability and a specification violation that browsers refuse to honour. With a wildcard allowed origin, any website could make authenticated requests to your API using your users’ cookies. With specific origins, only your own frontend can make authenticated requests. Always use specific allowed origins in production environments that handle authentication.

7-Step Debugging Guide When Nothing Seems to Fix the CORS Error

You have added the cors middleware. You restarted the server. The error is still there. Here is the methodical approach that always finds the problem:

  1. Confirm the backend is actually running and receiving requests. Open your browser and navigate directly to the backend URL: http://localhost:5000/api/users. If you get a response (even a JSON error), the backend is running. If you get a “connection refused” error, the backend is not running or is on a different port. Fix the running issue first before debugging CORS.
  2. Check the Response Headers in the Network tab of browser DevTools. Open DevTools, go to the Network tab, make the request from your React app, click the failed request in the list, and go to the Response Headers section. Do you see an Access-Control-Allow-Origin header? If there is no such header at all, the cors middleware is not running. If the header is present but has the wrong value, the allowed origin does not match your React app’s origin exactly.
  3. Check that the cors middleware is placed before all route definitions in Express. In your server file, look at the order of your app.use() calls. The cors() middleware must appear before any app.get(), app.post(), or app.use(‘/api’, router) lines. If routes are defined before cors is applied, those routes handle requests before CORS headers are added.
  4. Verify the allowed origin matches exactly what the browser sends. The Origin header the browser sends must exactly match what you configured in cors({ origin: ‘…’ }). Check the Network tab Request Headers for the Origin header. Copy that value exactly (no trailing slash, correct protocol, correct port) into your cors config. A mismatch of even one character prevents the browser from accepting the response.
  5. For the credentials wildcard error, change origin from ‘*’ to the specific origin. If you are getting the “wildcard not allowed with credentials” error, change origin: ‘*’ to origin: ‘http://localhost:3000’. Add credentials: true to your cors config. Confirm your fetch call includes credentials: ‘include’. All three must be consistent for authenticated cross-origin requests to work.
  6. Inspect the actual API response body by checking the JSON Formatter. Once CORS is fixed and you are getting responses through, paste the API response body into the JSON Formatter to see the exact structure. This is particularly useful when debugging API responses in development because the Network tab Response panel can be hard to read for deeply nested JSON objects, and understanding the structure is essential before writing React code that depends on it.
  7. For production deployments, check the ALLOWED_ORIGINS environment variable in your hosting platform. If CORS worked in development but broke in production, the most common cause is the allowed origin is still set to localhost:3000 rather than your production frontend URL. Log in to your hosting platform (Heroku, Railway, Render, AWS, etc.), find the environment variables section, and confirm ALLOWED_ORIGINS is set to your production frontend URL. Redeploy after the change if the platform requires it.

Frequently Asked Questions About CORS Errors in React

Why does my CORS error say “No Access-Control-Allow-Origin header” when I already added cors()?

There are three common reasons. First, the cors middleware is placed after your route definitions. Express middleware executes in the order it is defined: if a route handler runs before cors runs, the response is sent without CORS headers. Move app.use(cors()) to the top of your middleware chain, before any route definitions. Second, you may have restarted the frontend dev server but not the backend. The backend needs to restart for the new cors middleware to take effect. Third, confirm the cors package is actually installed. Run npm list cors and if it is not listed, run npm install cors and restart the server.

Why does the CORS error only appear for POST requests but not GET requests?

Simple GET requests and some POST requests with specific content types are called “simple requests” and do not trigger a preflight. However, a POST request with Content-Type: application/json is not a “simple request” and triggers a preflight OPTIONS request first. If your cors middleware is not handling OPTIONS requests, the preflight fails and the browser blocks the actual POST. Ensure your cors middleware is applied globally (not just to specific routes) and includes ‘OPTIONS’ in the allowed methods list. Using app.use(cors(config)) rather than route-specific cors handles this automatically.

Should I fix CORS with the proxy in package.json or by configuring the backend?

For long-term projects where you control the backend, configuring the backend to send correct CORS headers is the better solution. It works in both development and production, it is how CORS is intended to work, and it does not depend on the dev server setup. The proxy approach only works in development (the proxy field in package.json has no effect on production builds) and requires changing all your fetch URLs to relative paths. If you are calling a backend you do not control, or want a quick development workaround while you wait for backend changes, the proxy is fine. Just remember to add proper CORS headers to the backend before deploying to production.

My CORS is fixed in development but broken after deployment. What happened?

Almost certainly your allowed origin is still set to http://localhost:3000 in the production backend. The origin the browser sends in production is your production frontend URL (like https://app.yourdomain.com), which does not match localhost:3000, so the browser blocks the response. Check your production environment variables and update the allowed origin to your production frontend URL. If you are also using the React dev server proxy, remember that it only works in development: your production React app fetches directly from the backend URL, not through a proxy.

Is it safe to use cors() with no options (allow all origins) in production?

It depends entirely on whether your API uses authentication. If your API is fully public (no login, no user-specific data, no sensitive operations), allowing all origins with cors() is technically fine. Any website can already call your public API by other means. If your API uses cookies, session tokens, or Authorization headers, allowing all origins creates a security risk: a malicious website could trick a logged-in user’s browser into making authenticated requests to your API. In that case, always specify exact allowed origins and use credentials: true only for those specific trusted origins. When in doubt, be specific rather than permissive.

Why does adding Access-Control-Allow-Origin in the frontend fetch request not fix CORS?

This is one of the most common CORS misunderstandings. The Access-Control-Allow-Origin header is a response header: it must be sent by the server in its response, not by the browser in its request. Adding it to your frontend fetch call does nothing useful because the browser ignores custom Access-Control-* headers in requests. The fix is always on the server side: the server needs to include Access-Control-Allow-Origin: http://localhost:3000 in its responses. The browser reads this header from the response and decides whether to allow your JavaScript code to access the response body.

Free browser-based developer tools

Tools for debugging API responses once CORS is fixed

Inspect and format JSON API responses, compare responses between environments, convert data formats, and more. All free, all in your browser, no login required.

{ } JSON Formatter → ≠ Text Diff Checker → ⇄ JSON to YAML → ⇄ JSON to XML → Cc Case Converter → # Slug Generator →

CORS Is Not Your Enemy. It Is Just a Browser Enforcing a Contract Your Backend Has Not Signed Yet.

The moment this clicked for me was when I stopped thinking of CORS as a bug and started thinking of it as the browser asking the server for written permission. When you add app.use(cors({ origin: ‘http://localhost:3000’ })), you are telling the browser: my server explicitly permits requests from that origin. The browser sees that permission in the response headers and steps aside. Without that permission, it protects the user by blocking the response, exactly as designed.

The three takeaways that prevent the CORS confusion loop: CORS is enforced by the browser, not the server (which is why Postman works). The fix always lives on the backend, not in your fetch code. And in production, your allowed origin must be your production frontend URL, not localhost. Get those three things right and you will rarely fight CORS again.

Once your CORS error is resolved and API responses are flowing through, paste the response body into the JSON Formatter to understand the exact data structure before writing the React code that consumes it. Understanding the shape of the data first saves a lot of time debugging undefined property errors later.