What CORS changes

Cross-Origin Resource Sharing (CORS) is a provider-controlled policy expressed in HTTP response headers. For a simple request, the browser may send it but prevent your code from reading the response. A failed browser fetch therefore does not prove that the API is offline or that the request had no effect.

Why adding authentication can trigger a preflight

An Authorization header, a custom API-key header, or an application/json body can cause the browser to send an OPTIONS preflight first. The provider must permit the origin, method, and requested headers. A successful unauthenticated GET does not guarantee that authenticated requests will work.

Why there is no “disable CORS” switch here

Setting fetch mode to no-cors produces an opaque response that JavaScript cannot inspect. Adding Access-Control-Allow-Origin to your request does not grant permission; it is a response header controlled by the provider. Find Public APIs does not route requests through a proxy to bypass this policy.

Interpret errors carefully

Browser fetch often reports the same generic network error for CORS, DNS, TLS, offline connections, extensions, and blocked redirects. Open your browser’s Network panel to inspect the failing request and consult the provider’s browser guidance. This playground blocks redirects to avoid forwarding an authenticated request to another destination.

What you can inspect

When a request succeeds, the response panel shows status, duration, size, and browser-visible headers. Some headers remain hidden unless the provider explicitly exposes them. JSON can be explored as a tree or table; other text stays plain text, including HTML, to avoid running remote markup.

Further reading

Put it into practice.

Start with a reviewed guide or test a request in the playground.

Open the playground ↗Explore reviewed APIs →