You're testing a front end against an API that doesn't send CORS headers yet, and you just want Chrome to stop blocking it. You can — here's the exact command for each system — but read the warning, and consider the narrower options below it.
Close nothing — this starts a second, separate Chrome. The --user-data-dir part is required; without a separate profile Chrome ignores the flag.
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="%TEMP%\chrome-dev"open -na "Google Chrome" --args --disable-web-security --user-data-dir=/tmp/chrome-devgoogle-chrome --disable-web-security --user-data-dir=/tmp/chrome-devChrome shows a yellow bar saying you're using an unsupported command-line flag. That's how you know it worked.
The flag doesn't just switch off CORS for your API. It turns off the same-origin policy for every site in that window — so any page open there could read responses from any other site, including ones you are signed in to. That's why Chrome insists on a separate profile.
Instead of turning off security everywhere, you can add the missing Access-Control-Allow-* headers to responses from just the API you're testing, in your normal browser. Everything else keeps working as usual.
Two limits apply to any tool that does this:
OPTIONS preflight with an error (401, 404, 405…), headers can't turn that into a success. The server has to let OPTIONS through.Allow CORS for one site in one click, as a single switch you can turn off again. When a request on the current tab is blocked for CORS reasons, HeaderForge names the server that refused it and offers the fix right there — and says so plainly when the failure is a rejected preflight that headers can't fix. No account, no tracking.
Get HeaderForge for ChromeRoute API calls through your own dev server so the browser only ever talks to one origin. No CORS involved at all:
// vite.config.js
export default {
server: { proxy: { "/api": "http://localhost:8080" } }
};Then call fetch("/api/users") instead of the full URL. webpack-dev-server and Next.js rewrites do the same job.
Everything above only helps you. For your users, the API has to send the headers. CORS error: what it means and how to fix it has the server code, and the CORS tester shows exactly what a given request gets back.
More on this topic: How to disable CORS in Firefox (and why content.cors.disable makes it worse) · TypeError: Failed to fetch — what it actually means, and how to tell which cause · net::ERR_BLOCKED_BY_CLIENT, ERR_BLOCKED_BY_RESPONSE and ERR_BLOCKED_BY_ORB · “Has been blocked by CORS policy”: every variant and its fix