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 people reach for it to fix plenty of problems it doesn't solve. Below 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. When it is yours, change the server.
2. The error isn't 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. That way an oversized response fails with a clear 502 instead of arriving cut off, but it also 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 usual blocker is 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 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 daily quota on top. corsproxy.dev's free tier is 500 requests/day, and Pro raises that to 20,000 but doesn't remove it (details in our rate limits and quotas post). For a prototype that's a non-issue. For steady production traffic, fixing CORS at the source (case 1) removes both the hop and the quota. Self-hosting removes only the quota: a proxy you run yourself is still an extra hop. If you go that way, our open-source Go proxy is a separate, simpler relay than the hosted service, with no accounts, API keys, quotas or managed upstream headers. 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 use case, and it's why corsproxy.dev exists. The point is knowing which problem you have before reaching for it.