The IPFS web browsers integration group

Informal group working on improving IPFS presence in web browsers

Our goal is to facilitate native support for IPFS and other decentralized protocols in web browsers in order to benefit ....

• Browser users: Browser extensions and native-included IPFS alike expose IPFS features in a robust and intuitive way
• Web developers: Web developers can enjoy a smooth experience working with IPFS in browser contexts
• Browser vendors: Browser developers are empowered to meet the requirements of the distributed web

Contents

• Projects
  • IPFS Companion browser extension
  • IPFS and the JavaScript ecosystem
    • Helia
  • Browsers dialing nodes directly
  • How to address IPFS on the web
  • How to run own HTTP Gateway
  • How to implement HTTP Gateway
  • DNSLink
  • Collaborations
    • W3C
    • IPFS and Igalia collaborate on dweb in browsers
    • Brave
    • IPFS in Chromium
    • Opera
• Get involved!
• Resources

Projects

IPFS Companion browser extension

IPFS Companion is a browser extension that simplifies access to IPFS resources and adds browser support for the IPFS protocol. It runs in Firefox and Chromium-based browsers including Chrome or Brave. Check out all of IPFS Companion's features and install it today!

Notable past web extension experiments

• Mozilla hosted a community effort called libdweb to implement experimental APIs for Firefox WebExtensions, with a goal of enabling dweb protocols in Firefox through browser add-ons:
  • IPFS libdweb experiments, including a native protocol handler, local DNS-SD discovery and TCP transport
  • The long-term goal of this project was to integrate these APIs into the WebExtensions ecosystem, but as of Q3 2020 it is not yet in Firefox Nightly
• Exposing the IPFS API via window.ipfs (experiment ended in 2020)
• Support for chrome.sockets.* APIs in Chromium browsers (ended due to EOL 2022)

IPFS and the JavaScript ecosystem

Helia

Helia is a lean, modular, and modern TypeScript implementation of IPFS for the prolific JS and browser environments.

See the Manifesto, the FAQ, and the State of IPFS in JS blog post from October 2022 for more info.

Usage examples:

• examples at ipfs/helia
• an advanced, end-to-end example of using @helia/verified-fetch node in ServiceWorker can be found at https://inbrowser.link (sources)

Legacy JS-IPFS

The js-ipfs / ipfs-core is is no longer maintained. See State of IPFS in JS blog post from October 2022 for rationale.

Browsers dialing nodes directly

As of 2026 Q3, a browser can fetch content straight from an IPFS node, with no gateway in the middle. Three transports carry that traffic: /webrtc-direct and /quic-v1/webtransport need no signalling server and no CA-issued certificate, while /tls/ws uses a real certificate the node obtains on its own. All three keep moving as browsers change what they accept.

• 2024-05: service-worker-gateway is the client side of this: a Helia node running in a Service Worker that retrieves over WebTransport, Secure WebSockets, or plain HTTPS, and follows the subdomain gateway convention so every root CID lands on its own origin. A proof of concept was running at https://inbrowser.link.
• 2024-11: AutoTLS gets a publicly reachable node a wildcard certificate for *.[PeerID].libp2p.direct, so a browser can open a Secure WebSocket to it from a Secure Context without the operator registering a domain or handling a certificate. The p2p-forge client brokers an ACME DNS-01 challenge, and Let's Encrypt issues the certificate. Kubo ships it in v0.32 and enables it by default, under AutoTLS. A proof of concept broker was running at libp2p.direct.
• 2025-07: Kubo v0.36 turns its HTTP retrieval client on by default, so a node fetches blocks over plain HTTPS from providers that offer it. Browsers already retrieve this way through @helia/verified-fetch, and the same trustless gateway responses now serve both.
• 2026-07: go-libp2p v0.49.0 accepts the webrtc-direct v2 handshake alongside v1. Chrome has merged the removal of the SDP rewriting v1 depends on, behind the WebRTC-NoSdpMangleUfrag field trial, so a v1-only server stops being dialable from Chrome once that reaches stable. libp2p/specs#672 tracks the other implementations.
• 2026-07: the same release answers WebTransport draft-15 and the older session identifiers every shipping browser still sends. Firefox is implementing draft-15, and Safari 26.4 and later will not open a session unless the server sends the WT_MAX_SESSIONS limit from draft-14. More in go-libp2p#3532.
• 2026-07: Kubo v0.43 carries the two transport updates above to node operators, with nothing to configure. See its changelog.

How to address IPFS on the web

• For regular users, see
  • this guide to how to address IPFS content paths on the web
  • this reference about HTTP Gateway API
• For browser vendors and user agent developers, see the IPFS URI and IPNS URI specifications

How to run own HTTP Gateway

• If you are a desktop user, try IPFS Desktop
• If you only want to run a Gateway as a public HTTP server, and the data is provided by separate IPFS nodes, use the latest Rainbow, which is a specialized gateway daemon.
• If you want to host your own data and prefer to work with command-line, use the latest Kubo daemon and follow gateway recipes.
• If you have a lot of data, consider running Kubo with IPFS Cluster.

How to implement HTTP Gateway

See specification and implementer notes at https://specs.ipfs.tech/http-gateways/.

DNSLink

DNSLink enables you to map a domain name to an IPFS address (CID or IPNS libp2p-key) by means of a DNS TXT record.

• Read the DNSLink guide for details, including how to set it up on your own website
• See details on DNSLink in IPFS Companion to see additional benefits of using IPFS Companion with DNSLink support

Collaborations

W3C

Protocol Labs was a W3C Member until the end of 2024, and used that seat to watch and participate in the WebExtensions Community Group. The member list carried Protocol Labs on 2024-12-01 and no longer did on 2025-01-13.

• 2023-Q3: ServiceWorker-like protocol handlers for WebExtensions mentioned during WECG TPAC 2023 (notes)

WICG - Web Incubator Community Group

• 2024: IPFS features in web browsers

IPFS and Igalia collaborate on dweb in browsers

In 2020 IPFS and Igalia started a collaboration that continues to this day. Read more: https://blog.ipfs.tech/2021-01-15-ipfs-and-igalia-collaborate-on-dweb-in-browsers/

The most notable highlights (chronological order):

• IPFS and Igalia started a collaboration that will continue beyond 2021+
• Distributed web schemes have been safelisted in Chrome 86’s implementation of custom handlers and registered at IANA.
• Chrome 89 will allow browser extensions to register cross-origin handlers or handlers for schemes with prefix ext+. Refinement is pending for the permission UI.
• Firefox 84 marks http://*.localhost/ URLs as secure context, which means websites loaded from local subdomain gateway will have access to the same Web APIs as HTTPS version.
• Firefox 84 has improved support for loading locally delivered mixed-resources. Patches have also been submitted to WebKit but are pending on reviews and discussions.
• Work is in progress to improve Chromium’s consistency and specification compliance regarding the notion of secure contexts, including removing non-standard localhost names.
• Miscellaneous other fixes have landed for the Firefox and Chromium’s implementations of custom handlers.
• WIP refactor to make it easier to register custom protocol handlers (example, related talk: Integrating New Protocol Handlers into Chrome [BlinkOn 15])
• 2022-05-10: HTML spec PR: add IPFS and IPNS as safelisted schemes for registerProtocolHandler()
• 2022-05-18: Chromium status update: New Custom Handlers Component (BlinkOn 16)
• 2022-06-28: Explainer: Predefined Custom Handlers + Chromium discussion thread
• 2022-07-20: Chromium SchemeRegistry patch MERGED: New list in SchemeRegistry to manage schemes with predefined handlers
• 2022-08-03: After refactors, adding predefined, redirect-based handlers is 2 LOC – demo Implement Predefined Handlers for IPFS schemes using the SchemeRegistry
• 2022-08-01: Blogpost: New Custom Handlers component for Chrome
• 2022-09-28: Intent to Prototype: Curve25519 in Web Cryptography
• 2023-Q3: Kick-off work with Igalia on prototyping ServiceWorker-like protocol handlers for WebExtensions
• 2024-Q3: Curve25519 in Web APIs is implemented in Chromium and WebKit behind a runtime flag #, remaining work is around WPT and specification details.
• 2025-Q1: Prototyping New WebExtension API to register protocol_handlers in Chromium. The prototype was abandoned once the real implementation started, see the 2025-Q2 and 2025-Q3 entries below
• 2025-Q1: blogpost: Can I use Secure Curves in the Web Platform?, chromium: Ship the Ed25519 WebCrypto agorithm
• 2025-Q2: Ed25519 in WebCrypto ships enabled by default in Chrome 137
• 2025-Q2: the WebExtension protocol_handlers manifest key lands in Chromium
• 2025-Q2: throttling for pending WebTransport sessions lands behind a runtime flag, tuned against a browser libp2p app run with Interplanetary Shipyard
• 2025-Q3: the API that performs the handler registration lands, and work starts on the Chrome bugs blocking the Service Worker Gateway (issue 40410035)
• 2025-Q4: early-cancellation mitigation closes out the WebTransport work; permission handling lands as navigation interception and a prompt dialog
• 2026-Q1: protocol handler registration from extensions ships behind an experimental flag in Chrome 146
• 2026-Q1: blogpost: Protocol handler registration via browser extensions
• 2026-Q2: a Service Worker interceptor for download requests merges behind the ServiceWorkerInterceptDownloads flag, one of the blockers for the Service Worker Gateway
• 2026-Q3: error code mapping merges and issue 40410035 is fixed; work starts on Service Worker support in Tor Browser

Brave

• 2021: Brave v1.19 has integrated IPFS into their desktop web browser for Windows, macOS and Linux.
  • When Brave detected an address which is an HTTP gateway URL to IPFS content or a native IPFS address such as ipfs:// or ipns:// it prompted the user to install and enable the native IPFS node (Kubo), or to use an HTTP gateway.
  • Initial release (v1.19) was focused on daemon orchestration and on URI support (read blogs and press)
• 2024: After over three years, the Brave team decided to remove support for running IPFS node as we could not find a mutually agreeable set of terms to make this integration sustainable.
  • Users can retain their PeerID and onboarded data by switching to IPFS Desktop + Companion extension. More details at Migrating from Brave to IPFS Desktop.

ipfs-chromium

• 2023-Q3: Project introduction blogpost at IPFS Multi-Gateway Experiment in Chromium
• 2023-Q3: ipfs-chromium project ships first builds
• 2023-08-30: Intent to Experiment: Verifying IPFS client via HTTP APIs

Opera

Opera for Android 57 introduced support for resolving ipfs:// or ipns:// via a customizable gateway.
Read more: https://blog.ipfs.tech/2020-03-30-ipfs-in-opera-for-android/

Get involved!

Contribute to an issue

Contributions to our work are more than welcome! Every IPFS Project repo makes use of the project-wide global issue labeling scheme. Good labels to look for are ...

• help wanted
• good first issue

If you see an issue that catches your eye, leave a comment so we know you're interested, and we'll go from there!

We're an open project and a friendly group, so please be nice and read the contributing guidelines when you're ready to jump in.

Discuss

For the sake of async communication, archiving, and searchability, we encourage browser-related technical discussions to happen in the context of GitHub issue comments whenever practical.

If you want to ask support question, or just chat informally to learn and brainstorm, feel free to join chat community or discussion forum at https://discuss.ipfs.tech

Improve docs

https://docs.ipfs.tech is backed by the repo at https://github.com/ipfs/ipfs-docs – any help in improving docs related to browsers (or not) is appreciated!

Improve specs

Proof-read ipfs/specs and fill an issue for: (1) outdated specs (2) missing specs (3) bits that are confusing and need to be clarified.

Resources

If you're looking for endeavors related to IPFS browser integration work, these resources may be helpful.

• IPFS in Brave Browser: TLDR explanation how Brave supports IPFS out of the box (either as local node, or by delegating to a public gateway of user's choice)
• IPFS Companion: Harness the power of your local IPFS daemon directly inside your favorite Chromium or Firefox browser, enabling support for ipfs:// addresses, automatic IPFS gateway loading of websites and file paths, easy IPFS file import and sharing, and more
• IPFS Web UI: The IPFS dashboard shipped with the IPFS daemon or IPFS Desktop
• js-ipfs-core: Core IPFS implementation in JavaScript for use in browser (without Nodejs daemon parts)
• HTTP Gateway API docs - implementation-agnostic interface for trusted and trustless data retrieval
• HTTP RPC API docs: Guide to the RPC over HTTP API exposed when a Kubo IPFS node (go-ipfs) is running as a daemon; allows you to control the node and run the same commands you can from the command line
  • For up-to-date info about which JS client to use, see https://github.com/ipfs/kubo/issues/9125
• IPFS GUI group - The other half of the IPFS Web Browsers & GUI Working Group, dedicated to creating and implementing standards and patterns for IPFS that are simple, accessible, reusable, and beautiful