corsproxy.dev vs cors.sh: a side-by-side comparison

Both managed CORS proxies, both running on Cloudflare's edge. Unlike our hosted service and most competitors on our wider comparison, cors.sh publishes its code, so this comparison cites their own spec rather than only their marketing page.

Sep 30, 2026 · ~5 min read · Updated Oct 13, 2026

Disclosure: corsproxy.dev is our product. cors.sh figures come from their pricing page, homepage, and their own public source repo (specifically SPEC.md, which they describe as "the source of truth for how the service behaves") as of the date above.

At a glance

Where cors.sh is ahead

• A monthly free allowance instead of a daily one. On paper our free tier is larger: 500 requests/day is about 15,000 a month against their 10,000, and 250 MB/day is about 7.5 GB a month against their 5 GB. But ours is a daily cap that resets at 00:00 UTC, so you can never use more than 500 requests or 250 MB in one day. Theirs is counted per month, so uneven traffic (a launch day, a demo, a weekly batch job) isn't capped day by day. Check their pricing page for any short-window limit on free keys before you rely on that.
• Streaming architecture. Their spec describes the proxy streaming responses byte-for-byte with flat memory. corsproxy.dev buffers the whole response (up to 10 MB) so an oversized one fails with a clear 502 RESPONSE_TOO_LARGE instead of arriving cut off. That costs memory per request; streaming is lighter. (Our open-source Go relay streams too, and it silently truncates a body over its size limit.)
• Origin-pinning as the primary auth. Treating the key as public and the browser's Origin header as the boundary is a legitimate design: other websites can't use a lifted live_ key from their visitors' browsers, so there's less pressure to rotate it. Like our own origin lock, it doesn't stop a script outside the browser that sets its own Origin header.

Where corsproxy.dev is ahead

SSRF filtering in the proxy itself

cors.sh's SPEC.md lists the request checks they run: origin pinning, per-key target allowlists, the 6 MB size cap, rate limiting. Private-network and internal-address filtering isn't on that list, so nothing in the proxy as documented stops a live_ key with no allowedTargets from being pointed at http://169.254.169.254/ or an internal hostname. The backstop for both services is the same: a Worker on Cloudflare's edge can't reach private networks.

corsproxy.dev adds a layer on top of that. Literal private, loopback, link-local and metadata addresses are refused with 403 BLOCKED_HOST, and hostnames are resolved through Cloudflare's security resolver first, so a name that points at a private address is refused too. That check has limits we'd rather state than hide: it's a separate lookup before the fetch, it fails open if the resolver errors, and because resolve-then-fetch isn't atomic, DNS rebinding could in principle race it. Upstream redirects aren't followed; a 3xx comes back to your code as is. See how a CORS proxy can be abused for the wider argument.

A small open-source relay you can run yourself

cors.sh's source being public is notable; most competitors on our wider list aren't open at all. But their repo is the whole product: a Next.js console, Stripe billing, Auth.js accounts, D1 and KV bindings, built to run their own SaaS. Our hosted service isn't open source. What we publish is a simpler open-source CORS relay: one Go file with no external service dependencies, run with go run main.go or a single Docker container. It has no accounts, keys, daily quotas or managed upstream headers, and it forwards request headers (including Cookie and Authorization) as is, so review its settings before exposing it publicly.

Managed upstream headers

If your frontend calls an API that needs a secret key, corsproxy.dev can attach it server-side per request so it never ships to the browser. cors.sh's model doesn't have an equivalent; see calling OpenAI, Notion, and Google Sheets without leaking your API key.

Rate limiting on both

Neither service puts a short-window brake on production keys. cors.sh's Durable Object limiter (30 requests per 10 seconds) applies only to test_ keys; live_ keys rely on the monthly quota. corsproxy.dev has no per-second limit on any key: every request counts against a per-account daily quota, enforced atomically in a Durable Object. The practical difference is the size of the bucket a misused key can drain before it stops.

Switching between them

const target = 'https://api.example.com/data';

// cors.sh
fetch('https://proxy.cors.sh/' + target, {
  headers: { 'x-cors-api-key': 'live_YOUR_CORS_SH_KEY' }
});

// corsproxy.dev
fetch(`https://api.corsproxy.dev/proxy?url=${encodeURIComponent(target)}&key=YOUR_CORSPROXY_DEV_KEY`);

Note the different auth shape: cors.sh sends the key as a header with the target unencoded in the path; corsproxy.dev takes the target as a URL-encoded query parameter with the key alongside it (or as an X-API-Key header for server-side callers). Not a drop-in swap either direction; budget a few minutes to update the call site, not just the base URL.

Which one to pick

• Your traffic is uneven and a monthly allowance fits it better than a daily one: cors.sh, after checking its free-tier limits.
• You're proxying to targets you don't fully control, or want a documented SSRF stance: corsproxy.dev.
• You want a minimal relay to self-host in one command, without accounts or billing: our open-source Go relay.
• Your frontend needs to call an API with a secret key: corsproxy.dev, for managed upstream headers.
• You control the API you're calling: neither. Add CORS headers on your server; see how to enable CORS in Express.