Following up on our earlier post about moving IPFS users beyond centralized gateways, we have now begun redirecting users who navigate directly to ipfs.io and dweb.link to inbrowser.link .

This is a phased rollout, which will gradually increase over the coming days and weeks, as we verify the success of the rollout.

If you visit an IPFS link in your browser’s address bar via these trusted gateways, you will be transparently routed to the Service Worker Gateway deployed at inbrowser.link . This allows the gateway to run entirely in your browser, enabling trustless content verification and a more resilient access model. Like dweb.link, inbrowser.link is a Subdomain Gateway listed on the Public Suffix List . Each CID is served from its own subdomain, so the browser treats it as a distinct origin and the same per-site isolation you rely on with dweb.link carries over to inbrowser.link.

Why this matters

Public-good gateways were instrumental for early adoption, but they represent a single point of failure and operate on delegated trust. They also depend on ongoing external funding, which is inherently finite and cannot be assumed to scale indefinitely with demand.

Moving to a Service Worker Gateway shifts more of the verification locally into the user’s browser, decreasing the need to trust a centralized operator while also supporting a more sustainable and scalable model — without requiring users to install custom software or background processes.

Issues?

If you experience any problems with the redirect or the performance of inbrowser.link, please report them on the IPFS Service Worker Gateway GitHub repo .

For API and non-browser users

If you use public gateways for hot-linking images/videos or within non-browser applications, please begin migrating to self-hosted or verified alternatives. We will be rolling out additional rate-limits on the legacy gateways over the course of the year.

You can explore self-hosting tools like Rainbow for dedicated gateway needs, or use Verified Fetch as a drop-in replacement for fetch().

If you require assistance migrating, please reach out ahead of these changes.

Verifiable ENS

For our ENS users: Historically, resolving ENS via gateways required delegating trust to third-party resolvers.

We are now exploring ways to make ENS resolution verifiable directly through inbrowser.link. If you are interested in contributing to, or testing this work, please reach out or join the discussion here .