IPFS Public Gateway Checker: mapping online status and origin isolation

Public gateways carry no SLA, and the checker shows which ones currently answer

IPFS Public Gateway Checker is a web app hosted at https://ipfs.github.io/public-gateway-checker/ that tests public IPFS HTTP gateways and shows which ones respond. Its audience is anyone who needs to fetch IPFS content over HTTP without running a local node: developers checking which gateway to use for a demo, or anyone who wants a quick view of which servers are currently up.

The project is unambiguous about its scope. Public gateways are best-effort, carry no SLA, and can rate-limit, change, or go offline at any time. A production application that cannot run a full peer-to-peer stack and needs an HTTP gateway or delegated routing should run a self-hosted IPFS stack end-to-end, and the README points to the documentation for doing that. The checker does not solve the production case.

That framing is unusual for a project of this type. Most tools in this category position themselves as production-grade solutions, yet this one directs you away from its own gateway list the moment you try to use it for something serious. It names the self-hosting alternatives in the same opening paragraph.

The Origin column separates gateways with site isolation from those that share session data

The most security-relevant output of the checker is the Origin column. For complex websites and apps, the README says to use only gateways with a checkmark in that column. A gateway with a warning sign lacks origin isolation: all sites served through it share localStorage, cookies, and session data.

That sharing matters when two separate IPFS sites land on the same gateway. A site with malicious JavaScript could read the cookies and localStorage written by a legitimate one, because they share an origin. Issue #150 in the repository covers the full explanation of why this boundary matters.

Wallets and decentralized applications get a stricter warning. For those use cases, the README says to self-host your gateway on a local machine using IPFS Desktop or Kubo, treating the entire public list as unsuitable regardless of how each gateway scores in the Origin column. A checkmark means origin isolation is configured; it does not mean the operator is trustworthy or that the service will stay online.

Building and running locally requires npm ci, npm run build, and npm start

To run the project locally, the README gives three commands in sequence:

npm ci
npm run build
npm start

After those complete, the checker is available at http://localhost:3000/. The `engines` field in package.json sets the minimum at Node.js 16.0.0 and npm 7.0.0. The build step calls `aegir build`, copies the HTML and CSS assets to the dist directory, then runs a service worker build script at `scripts/build-sw.mjs`. The `npm start` entry in package.json chains `npm run build` with `npx -y serve -l 3000 dist`, which serves the compiled output.

Reaching http://localhost:3000/ from Tor Browser needs two changes in `about:config`: `network.proxy.allow_hijacking_localhost` set to `true` and `network.proxy.no_proxies_on` set to `localhost, 127.0.0.1`. The README says to reset both when testing is done. Tor Browser's default routes all localhost requests through Tor, so without those changes the local checker is unreachable from inside it.

Once built, the output is a static site and no persistent server process is needed beyond `serve`. Using `npx -y` means no globally installed copy of `serve` is required before running `npm start` for the first time.

gateways.json puts new entries at the top of the array, not the bottom

Regular gateway entries live in `gateways.json` at the repository root. Adding a new one means editing that file and placing the new address at the top of the array, not appending it at the end. After the edit, a pull request completes the submission, and the README asks contributors to follow all the directions in the pull request template so the PR can be triaged quickly.

For anyone submitting a gateway intended for use with web applications, the README recommends configuring it as a subdomain gateway. A subdomain gateway routes each content identifier to its own origin rather than serving everything from one shared domain. That setup is what produces a checkmark in the Origin column, while a path-based gateway, which serves all content under one domain, receives a warning sign instead. Kubo configuration documentation and a set of Kubo recipes are linked from the README for setting up a subdomain gateway.

The repository also includes a `test-gateways` npm script that calls `scripts/test-gateways.mjs`, but the README does not describe its role in the pull request review process or whether it runs automatically in CI.

Onion gateways live in a separate file and need Tor Browser to test

A second JSON file, `onion-gateways.json` at the repository root, holds the list of gateways on `.onion` addresses. The process for adding one mirrors the regular gateway workflow: edit the file, then submit a pull request.

Onion gateways are only testable via Tor Browser, and reaching a locally running instance of the checker from inside Tor Browser requires the same `about:config` changes described for local development. Both `network.proxy.allow_hijacking_localhost` set to `true` and `network.proxy.no_proxies_on` set to `localhost, 127.0.0.1` must be edited before http://localhost:3000/ is reachable. Without those changes, Tor Browser proxies localhost requests through the Tor network. The README says to reset both settings when testing is done.

The README does not document how many onion gateways appear in the list at any given time. The hosted checker at https://ipfs.github.io/public-gateway-checker/ is the only documented way to view their current status without running the project locally.

IPFS Foundation operates three of the listed gateways; every other entry is unverified

One fact in the README's security notes changes how the gateway list should be read: no central authority governs it. Only three of the listed gateways operate under the IPFS Foundation: `ipfs.io`, `dweb.link`, and `trustless-gateway.link`. Every other entry was added by a community contributor, and its operator, uptime, and policies are the contributor's own.

A gateway's online indicator in the checker says nothing about who runs it, under what terms, or whether it will respond to the next request. A checkmark in the Origin column means origin isolation is configured on that server; it does not imply anything about the operator's reliability or continuity of service, and there is no recourse listed in the project for a gateway that disappears.

This is not a gap in the checker. It says this plainly. The visual design, which shows green status indicators and checkmarks, can create an impression of reliability that the opening paragraphs directly contradict. Among all the gateways on the list, only those three have any documented operator backing them.

Three test scripts in package.json are named test-TBD rather than test

A close reading of package.json turns up a detail about the test suite that a skim of the README would miss. The scripts object has three entries for running tests: `test-TBD`, `test-TBD:node`, and `test-TBD:browser`. Each maps to an aegir test command (`aegir test`, `aegir test --target node`, and `aegir test --target browser` respectively), but there is no entry named `test` in the object. That absence matters because the conventional npm invocation for running a project's tests looks for a script named `test`. Nothing in the README addresses the `-TBD` naming.

The current release is v1.23.3 from 2026-08-21, and the last push was on 2026-09-25. The `license` field in package.json reads `"Apache-2.0 OR MIT"`, a dual SPDX expression; the repository root holds `LICENSE-APACHE` and `LICENSE-MIT` as separate files.

Editorial conclusion

Use this checker for demos and testing when you need a public IPFS gateway and do not want to run your own node. For any app that handles wallets, dapps or session-sensitive data, the README explicitly says to self-host using IPFS Desktop or Kubo rather than trusting any gateway on this list. Before adopting a gateway, confirm the operator behind it: the IPFS Foundation operates only `ipfs.io`, `dweb.link`, and `trustless-gateway.link`, and all other entries are community-submitted with no contractual guarantee.

Frequently asked questions

Official sources

1. ipfs/public-gateway-checker on GitHub
2. Issues
3. Project website
4. README
5. Releases