When not to use a CORS proxy
A CORS proxy fixes exactly one problem: a response that's missing Access-Control-Allow-Origin, from a server you can't add it to. That's a narrow job, and it gets reached for a lot of problems it doesn't actually solve. Here are six of them, including a few that apply to corsproxy.dev itself.
1. You control the server the request is going to
If the API is yours, the correct fix is on the server: set Access-Control-Allow-Origin for the origins that should be allowed, and you're done. No proxy in the request path, no added hop, no second service to keep available. Our own Express CORS guide covers the one-line dev fix and the production allowlist. A proxy is what you reach for when the server isn't yours to change — not a substitute for changing it when it is.
2. The error isn't actually CORS
"Blocked by CORS policy" is specific console wording, and a lot of requests that fail for other reasons get misdiagnosed into it. A Content-Security-Policy directive blocking the connection, a redirect that drops the CORS headers on the hop, a plain network error, or an ad blocker intercepting the request can all look similar from the Network tab. Routing a CSP-blocked request through a proxy changes nothing — the browser still won't let the response through a directive it's already refusing to load. Read the exact console message first; our practical guide walks through telling these apart before you reach for anything.
3. You need WebSockets, SSE, or large file transfers
The WebSocket handshake doesn't use CORS at all — there's no preflight, and the server is expected to check the Origin header itself instead of relying on the browser to enforce it. A CORS proxy has nothing to add there and, in our case, nothing to do: corsproxy.dev only accepts http:// and https:// target URLs, so a ws:// or wss:// target is rejected outright.
Streaming responses hit a related wall. corsproxy.dev reads the full upstream response into memory before returning it, capped at 10 MB in each direction — a design that makes byte-accounting exact, but means Server-Sent Events, chunked long-poll responses, and anything larger than that cap don't work through it. That's not a corsproxy.dev-specific gap; any proxy built the same way has the same ceiling. If your traffic looks like this, terminate the connection on your own backend instead.
4. An exposed secret is the real blocker, not CORS
If the target API already sends CORS headers — plenty of public APIs do — but you can't call it from the browser anyway, the problem usually isn't CORS, it's that the request needs an API key you can't put in client-side JavaScript. Piping that request through a bare CORS proxy that just forwards your headers doesn't fix this: the key still has to originate somewhere, and if it's typed into the browser first, it's already public. We wrote up the actual fix — keeping the secret server-side without standing up a backend — in calling OpenAI, Notion, and Google Sheets from the browser. A CORS proxy only helps here if it can inject the secret itself; a pass-through one just relocates the leak.
5. The target doesn't want to be called cross-origin
Some APIs withhold CORS headers on purpose — to keep browser usage restricted to first-party frontends, to require a signed backend-to-backend request, or to enforce per-key rate limits that a shared browser origin would break. Routing around that with a proxy is a technical workaround, not a fix, and it can put you on the wrong side of the target's terms of service. Check what the API's docs say about browser access before you build a proxy step into your production flow — including through corsproxy.dev.
6. Production volume where the hop and the quota both cost you
A proxy adds one more network round trip to every request, and a managed one adds a shared daily quota on top — corsproxy.dev's free tier is 500 requests/day, and paid tiers raise that but don't remove it (details in our rate limits and quotas post). For a prototype that's a non-issue. For steady production traffic in the thousands of requests a day, either fixing CORS at the source (case 1) or self-hosting the OSS proxy core removes both the extra hop and the quota — see self-host vs managed for the tradeoff in full.
When a proxy is still the right call
None of this means a CORS proxy is never the answer. If you're calling someone else's API from the browser, the target won't add the header, a backend isn't worth building for what you're doing, and you're not moving enough volume for the quota or the extra hop to matter — that's the actual use case, and it's why corsproxy.dev exists. The point is knowing which problem you have before reaching for it.