api.codetabs.com proxy is down: what to do

If your frontend calls api.codetabs.com/v1/proxy and everything broke sometime after early June 2026, it isn't your code. The codetabs CORS proxy was switched off by its maintainer following an abuse suspension, and it has not come back. Here's how to confirm that in one command, what the people who depended on it moved to, and how to pick a replacement that won't repeat the same ending.

Oct 9, 2026 · 10:05 UTC · ~6 min read

What happened

The sequence is documented in the open issue jolav/codetabs#43, filed on 6 June 2026 when the host stopped answering. Two days later the maintainer replied that the server had been suspended over an abuse notification. On 9 June they reported the API itself was back, and added: "CORS PROXY is disabled. I don't know if it will work again, and if it does, under what conditions". A week later another user thanked them for keeping it running as long as they had.

Nothing in that thread reads like a maintainer being careless. It reads like the normal end state of running an open relay for free: the traffic that gets you suspended is not sent by the people you built it for. We wrote about that failure mode in detail in how a CORS proxy can be abused, before this particular instance of it happened.

Confirm it in one command

Before you change any code, check the endpoint directly so you know you're debugging the right thing:

curl -o /dev/null -w '%{http_code}\n' \
  "https://api.codetabs.com/v1/proxy?quest=https://example.com"

At the time of writing that returns 503, and https://codetabs.com/ itself returns 522 — the whole host is unreachable, not just the proxy path. A 503 or 522 here means the service is down at their end. It is not a CORS failure, even though your browser console will probably show you a CORS error message: when the proxy never responds, the response carries no Access-Control-Allow-Origin header, so the browser reports the symptom it knows about rather than the outage underneath. Checking with curl, outside the browser, removes that ambiguity.

How much code points at it

This broke a lot of projects quietly. GitHub's code search for api.codetabs.com/v1/proxy reports roughly 9,200 matching files at the time of writing. Most of them are hobby projects, dashboards, and demos whose owners have not noticed yet, because a dead CORS proxy fails silently in someone else's browser rather than in your logs.

If you maintain anything that fetches third-party data client-side, searching your own repositories for the string codetabs is worth the thirty seconds.

Where its users went

Mostly to allorigins. In Google Trends worldwide data for the twelve months to October 2026, allorigins is the top rising related query for "cors proxy", "free cors proxy", and "corsproxy" alike, and the search interest spike for those terms lands exactly on the weeks of 7 and 14 June 2026 — the two weeks following the codetabs suspension.

That is an understandable move and a risky one. AllOrigins is another free, unauthenticated, shared proxy, which is to say it has the same economics that just took codetabs offline. Its reliability today is also uneven: checking both documented endpoints while writing this, https://api.allorigins.win/raw?url=... answered 200 while https://api.allorigins.win/get?url=... returned 520 and 522 on consecutive attempts. Treat any single free shared host as a dependency that can disappear between one deploy and the next, and see our free CORS proxy comparison for how the current options actually differ.

Pick a replacement in the right order

Swapping one free host for another is the fastest fix and the one most likely to leave you here again. In rough order of how durable the answer is:

• Check whether you need a proxy at all. Same-origin policy is enforced by browsers. If the failing request comes from a server, a cron job, a build step, or a mobile runtime that isn't a browser, delete the proxy and call the upstream directly. When not to use a CORS proxy covers the other cases.
• Fix it at the origin if you control it. One Access-Control-Allow-Origin header on your own API beats any amount of relaying. See Access-Control-Allow-Origin for the exact semantics, including why * and credentials don't combine.
• Self-host a proxy. Our proxy core is MIT-licensed Go: go run main.go on GitHub. You own the abuse problem, which is the honest trade — you also own the uptime, which is the point.
• Use an authenticated managed proxy. Keys, quotas, and a paying floor are what stop a proxy from becoming an open relay and getting suspended. That is what we sell, and it is also why self-host vs managed is a real decision rather than a sales pitch.

The migration diff, if you pick us

codetabs took the target URL in a quest query parameter. We take it in url, plus a key:

// Before — codetabs
fetch('https://api.codetabs.com/v1/proxy?quest=' +
      encodeURIComponent('https://api.example.com/users'))

// After — corsproxy.dev
fetch('https://api.corsproxy.dev/proxy?url=' +
      encodeURIComponent('https://api.example.com/users'), {
  headers: { 'X-API-Key': 'sk_live_...' }
})

Browser code can pass the key as a key query parameter instead of a header, which keeps the change to a single string. Leave the key out entirely and the call fails loudly rather than mysteriously:

curl "https://api.corsproxy.dev/proxy?url=https%3A%2F%2Fexample.com"
# {"success":false,"error":"Missing API key: send it in the X-API-Key header
#  or the key query parameter","code":"MISSING_API_KEY"}

The free tier is 500 requests a day with no card, and Pro is 20,000 a day at $5 a month. Keys are origin-locked, so a key lifted from your frontend bundle doesn't work from anywhere you didn't list — which is the mechanism that keeps our proxy from turning into the thing that got codetabs suspended.

What to take from this

Free shared CORS proxies don't usually announce a shutdown; they get a suspension notice and go quiet, and the people who depended on them find out from a browser console weeks later. Whatever you move to, add one check that tells you first: a scheduled request against your proxy endpoint that alerts you on a non-2xx. We publish our own at status for exactly that reason.