What Is IPFS: Complete InterPlanetary File System Guide (2026)

The internet you use every day runs on a simple promise: type an address into your browser, and a specific server somewhere in the world sends back the file. That model has powered the web for three decades, but it has a critical weakness. The file lives in one place. If that server goes down, gets censored, or simply forgets to renew a domain, the content disappears forever. The InterPlanetary File System, better known as IPFS, was built to solve exactly this problem by reimagining how files are addressed and shared on the internet.

IPFS is not a single company, a blockchain, or a cloud storage service in the traditional sense. It is a peer-to-peer protocol that lets anyone store and serve files using content-based addressing instead of location-based addressing. Instead of asking "give me the file at this server," IPFS lets you ask "give me the file with this fingerprint," and any node on the network that has the file can answer. This subtle shift unlocks a massive set of capabilities: permanent links, censorship resistance, deduplication at the protocol level, offline operation, and a foundation for Web3 applications that do not rely on centralized hosting.

In this complete guide, you will learn what IPFS actually is and is not, how content addressing works under the hood with CID identifiers, why NFTs rely on it for metadata, the pinning services landscape, how IPFS gateways quietly recentralize the network, the new Helia implementation that replaced js-ipfs, and where IPFS fits alongside Filecoin. By the end, you will understand IPFS deeply enough to upload your first file, evaluate a pinning provider, and spot the gotchas that most articles never mention.

What Is IPFS, Really?

IPFS, short for InterPlanetary File System, is an open-source peer-to-peer protocol designed to make the web faster, more resilient, and more open. It was created by Juan Benet in 2014 through Protocol Labs, the same organization that later launched Filecoin. At its core, IPFS replaces the location-based addressing of HTTP with content-based addressing, and it builds a distributed network of nodes that can store and retrieve content without depending on any central authority.

Here is the critical mental shift. When you visit a website over HTTP, your browser asks a specific server for a specific path. The URL https://example.com/photo.jpg tells your browser where to go, not what to get. With IPFS, you ask for a file by its CID, a cryptographic hash of the file's contents. The network finds any peer that has the file and serves it to you. The address is the content itself.

One critical point: the protocol does not actually store anything on its own. IPFS is an addressing and routing system. The files live on the nodes that choose to host them. If no node hosts a particular CID, that content simply does not exist on the network anymore, even though the address remains valid forever. This is why pinning services exist, and why uploading an NFT image to IPFS without pinning is one of the most common mistakes in NFT projects.

Content Addressing: The Core Idea

Content addressing is the single most important concept in IPFS. Instead of identifying a file by where it lives, you identify it by what it is. Every file added to IPFS is run through a cryptographic hashing algorithm, typically SHA-256, which produces a fixed-length digest unique to that exact file. Change one bit of the file and the hash changes completely. This hash becomes the foundation of the file's CID, its permanent address on the network.

The implications of this are enormous. Two identical files anywhere in the world will have the same CID, which means IPFS deduplicates content automatically. If a million people upload the same cat picture, the network only needs one copy. A CID is also tamper-proof in a way that HTTPS URLs are not. When you fetch /ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi, the content you receive must hash to that exact CID, or your IPFS client will reject it. There is no way for a malicious node to serve you modified content under the same address.

Large files are not hashed as a single blob. IPFS splits them into smaller chunks (typically 256 KB each), hashes each chunk, and then builds a Merkle directed acyclic graph (DAG) where each node references its children by hash. The CID you get back is the hash of the root node, which transitively commits to every chunk in the file. This structure is called dag-pb in the IPFS world, and it is the legacy default. Newer content uses ipld (InterPlanetary Linked Data), a more flexible data model that supports JSON, CBOR, and other encodings.

CID v0 vs CID v1: What Is the Difference?

If you have ever uploaded something to IPFS, you have probably seen two very different-looking CIDs. The old style starts with Qm and looks like QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG. The new style starts with b and looks like bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi. These represent CID v0 and CID v1, respectively, and the difference matters in production.

CID v0 is the original format. It is always a SHA-256 hash of dag-pb-encoded content, base58 encoded, starting with Qm. It is short and recognizable, but it is also rigid. There is no room for different hash functions, different encodings, or different bases. CID v1 is the modern, flexible format. It is a self-describing identifier that explicitly encodes the version, the codec, the multihash function used, and the base encoding. This means a CID v1 can represent SHA-256 dag-pb, but it can also represent BLAKE3 IPLD, raw bytes, or anything else the protocol supports.

The biggest practical reason to prefer CID v1 today is subdomain gateway support. Modern IPFS gateways serve content from URLs like https://bafybei...ipfs.dweb.link, which gives each CID its own browser origin. That origin isolation is essential for security (cookies, local storage, service workers) and only works with case-insensitive base32 encoding, which is CID v1. If you are publishing anything in 2026, default to CID v1 unless you have a very specific reason not to.

libp2p: The Networking Layer Underneath

IPFS is built on top of a modular networking stack called libp2p. This is one of the most important pieces of infrastructure to come out of Protocol Labs, and it is used by many other projects beyond IPFS, including Ethereum 2.0, Polkadot, and various Web3 protocols. libp2p handles everything that traditionally requires a network stack: peer discovery, connection management, NAT traversal, transport encryption, multiplexing, and stream protocols. It abstracts away the messy reality of peer-to-peer networking so higher-level protocols like IPFS can focus on their own logic.

Peers in libp2p are identified by a unique PeerID, which is itself a hash of the peer's public key. This means peer identity is cryptographic and self-sovereign, very similar to how addresses work in crypto wallets. Peers find each other through a distributed hash table (DHT) based on Kademlia, which lets the network route content requests efficiently without any central directory. When you ask for a CID, your node queries the DHT to find which peers are advertising that they have it, then connects directly to those peers to download the content.

libp2p supports multiple transports including TCP, QUIC, WebSockets, and WebRTC. WebRTC is what makes IPFS work in browsers, since browsers cannot open raw TCP connections. This flexibility lets IPFS run on everything from embedded devices to browser tabs to production servers, all speaking the same protocol.

How Content Retrieval Works: Bitswap

The actual mechanism that moves bytes between IPFS peers is called bitswap. It is a relatively simple protocol with a powerful idea: each peer maintains a "want-list" of CIDs it is looking for, and a "have-list" of CIDs it can provide. When two peers connect, they exchange these lists, and any time a peer receives a block that another peer wants, it sends it over.

When you request a CID, your IPFS node first checks its local cache. If the content is there, you get it instantly. If not, the node queries the DHT to find peers that have advertised the CID, connects to them via libp2p, and uses bitswap to download the blocks. For large files split across many blocks, your node might pull different blocks from different peers in parallel, which improves performance and makes the network more resilient to individual peer failures.

There is no monetary incentive built into bitswap by default. Peers serve content because they want to, or because they have been paid to by a service running on top of IPFS. This is one of the key differences between IPFS and Filecoin, which we will cover in detail later. Bitswap has no notion of payment; it is pure best-effort peer-to-peer exchange.

Pinning: Why It Matters and Who Does It

Here is the most misunderstood thing about IPFS. If you upload a file to IPFS and nobody pins it, that file will eventually disappear. IPFS nodes have limited cache space, and they routinely garbage-collect old content that nobody is actively keeping. The CID remains valid, the protocol still knows how to find that content if someone provides it, but the actual bytes are gone. Pinning is the act of telling an IPFS node "do not delete this content, no matter what."

You can pin content on your own node, which is fine for personal projects, but in production you almost always rely on a pinning service. These are companies that run robust IPFS infrastructure and guarantee they will keep your CIDs available for as long as you pay them. The pinning services landscape in 2026 is mature and competitive, with several solid options serving different use cases.

Choosing a pinning service depends on your priorities. If you need rock-solid uptime and good developer ergonomics, Pinata is the safe default. If you want long-term durability with Filecoin deals included, Storacha is purpose-built for that. If you are deploying a dApp frontend, Fleek's Git integration saves you hours of CI setup. If you are running a small project and want zero recurring spend, a self-hosted Kubo node with good monitoring is perfectly viable.

IPFS Gateways and the Centralization Problem

If IPFS is a peer-to-peer protocol, how does your browser load /ipfs/CID URLs? It does not, at least not natively. Mainstream browsers do not speak the IPFS protocol. To make IPFS content accessible over the regular web, the community built gateways: HTTP servers that act as bridges between the IPFS network and ordinary browsers. You request https://ipfs.io/ipfs/bafybei..., the gateway fetches the content from the IPFS network, and serves it back to you over HTTPS.

Gateways are incredibly useful, but they introduce a quiet centralization problem that the IPFS marketing materials often gloss over. The two dominant gateways, ipfs.io (run by Protocol Labs) and cloudflare-ipfs.com (run by Cloudflare), serve a huge fraction of all IPFS traffic. When most NFT marketplaces, dApps, and educational sites use these gateways to serve IPFS content, the protocol's decentralization story gets weaker. If Cloudflare blocks a CID, or ipfs.io has an outage, large portions of "decentralized" content become temporarily unreachable for users who never installed a real IPFS client.

The mitigations are well known but underused. First, link to content via multiple gateways or use a fallback gateway list, so a single operator going down does not break your site. Second, prefer subdomain gateways like https://CID.ipfs.dweb.link over path gateways, because they isolate each piece of content in its own browser origin. Third, encourage users who need real censorship resistance to run their own node or use Brave, which has IPFS built in. Fourth, projects that care about long-term resilience should run their own gateway in addition to using public ones.

Helia vs Kubo: The Modern IPFS Stack

For most of IPFS's history, there were two main implementations: Kubo (originally called go-ipfs), the reference implementation written in Go, and js-ipfs, the JavaScript implementation. Kubo runs as a daemon and is what powers most production IPFS infrastructure, including pinning services and gateways. It is mature, performant, and battle-tested.

js-ipfs let IPFS run in browsers and Node.js apps but carried a lot of legacy code and was hard to maintain. In 2023, Protocol Labs began transitioning to Helia, a fresh implementation with a leaner, more modular architecture. By 2025, js-ipfs was deprecated and Helia became the recommended choice for JavaScript projects. In 2026, start with Helia for anything new.

Helia is not a drop-in replacement. The API is different, the dependency graph is smaller, and the philosophy is "bring your own pieces": choose your own blockstore, datastore, and routing, plug them into Helia, and you have a working node. This makes Helia much easier to embed into modern stacks. Migration guides exist for js-ipfs projects.

IPFS vs HTTP: A Side-by-Side Comparison

The most useful way to understand IPFS is to compare it directly with HTTP, the protocol it builds on top of and partially replaces. They are not enemies, and most production IPFS use cases involve HTTP somewhere in the stack, but the design philosophies are very different.

The realistic verdict in 2026 is that IPFS and HTTP coexist rather than compete. HTTP is excellent for dynamic content, sessions, and high-throughput applications. IPFS is excellent for static, addressable, long-lived content where integrity and resilience matter more than millisecond latency. Most production stacks use HTTP for the dynamic layer (APIs, user auth) and IPFS for the immutable layer (images, NFT metadata, dApp frontends).

IPFS vs Filecoin: Clarifying the Relationship

There is constant confusion between IPFS and Filecoin, partly because both were created by Protocol Labs and partly because their marketing materials sometimes blur the lines. Here is the clean version: IPFS is the protocol for addressing and moving content. Filecoin is a blockchain-based storage market that pays nodes to host content for guaranteed periods. They are complementary, not interchangeable.

IPFS has no economic layer. Nodes serve content out of goodwill or because they have been paid by some service running above the protocol. There is no built-in guarantee that a CID will remain available. Filecoin solves this problem by creating a marketplace where storage providers commit cryptoeconomic stake to keeping specific content available for specific durations. If a Filecoin provider fails to prove they still have your data through their regular cryptographic proofs, they lose part of their collateral. This creates the economic incentive that pure IPFS lacks.

The clean way to think about it: use IPFS for retrieval and addressing, and use Filecoin for durable, paid storage commitments. Modern pinning services like Storacha and NFT.Storage do both. They pin your content on IPFS for fast retrieval and also make Filecoin storage deals so the content has long-term cryptoeconomic guarantees. You get the speed of IPFS and the durability of Filecoin in one stack.

NFT Metadata: Why IPFS Became the Standard

When you mint an NFT, the actual image or media file is almost never stored on the blockchain itself. Storing a multi-megabyte JPEG on Ethereum would cost a fortune in gas fees. Instead, the NFT contract stores a metadata URI, which points to a JSON file containing the image URL, traits, and other attributes. The integrity of an NFT depends entirely on whether that metadata URI keeps resolving to the correct content.

This is where IPFS became the de facto standard. If you use a regular HTTPS URL for your NFT metadata, you are one server outage away from broken NFTs. Worse, you could swap out the image after the mint and nobody would know without checking your server logs. With IPFS, the URI is ipfs://CID, which points to a specific cryptographic hash. The content cannot change. Any node that serves a different file for that CID is immediately detectable, because the hash would not match.

The catch, and this is the most common NFT mistake, is that uploading to IPFS does not keep your file alive. If you upload to your local node and shut it down without pinning anywhere else, your NFTs are dead. Reputable projects pin to at least one professional service, serious ones pin to multiple and make Filecoin deals. When NFT projects break years after the mint, it is almost always because the team stopped paying the pinning bill.

dApp Frontend Hosting on IPFS

Beyond NFTs, the second major production use case is hosting decentralized application frontends. A modern dApp has a smart contract backend on Ethereum and a JavaScript frontend. If the frontend lives on a regular cloud provider, the dApp's decentralization claim is mostly fiction. The smart contract is on-chain, but if the team's domain or hosting goes down, users cannot access it.

By deploying the frontend bundle to IPFS, the dApp is accessible at /ipfs/CID permanently, and any IPFS gateway can serve it. Combined with decentralized identity and a human-readable name via ENS or dnslink, you get a fully addressable, censorship-resistant frontend. Uniswap, Aave, and other major DeFi protocols publish IPFS builds for this reason.

IPNS and DNSLink: Mutable Names on Immutable Content

Content addressing is wonderful, but it has an obvious limitation: every time the content changes, the CID changes. If your dApp deploys a new version, every existing link breaks. To solve this, IPFS provides two layers of indirection: /ipns/ (the InterPlanetary Name System) and dnslink.

IPNS lets you publish a stable, peer-key-based pointer to a CID that you can update over time. The pointer itself is a hash of a public key, and you sign updates with the corresponding private key. Other nodes can verify those updates and route requests for the IPNS name to the current CID. The address looks like /ipns/k51qzi5..., which is stable forever, while what it points to can change.

DNSLink takes this a step further by letting you map a regular domain name to an IPFS CID through a TXT DNS record. You create a TXT record like _dnslink.example.com with the value dnslink=/ipfs/CID, and IPFS-aware tools resolve the domain to the current CID. This is how dApp frontends get human-readable URLs while still serving content from IPFS. Every time you deploy, you update the DNS record, and users still hit the friendly domain.

Hands-On: Uploading to Storacha and Pinata

Theory is fine, but the fastest way to internalize IPFS is to actually pin something. Both Storacha and Pinata offer generous free tiers and excellent developer experience. Here is the practical flow for each.

With Storacha, sign up at storacha.network with an email. The service will email you a confirmation, and once you click through, you create a "Space" which is a namespace for your uploads. You install the w3 CLI with npm install -g @web3-storage/w3cli, log in with w3 login your@email.com, select the Space, and upload with w3 up ./my-file.jpg. You get back a CID immediately. The file is pinned on Storacha's IPFS nodes and queued for Filecoin storage deals.

With Pinata, sign up at pinata.cloud, create an API key with pinning and listing scopes, and use either the web upload interface or the API. From the dashboard, you literally drag and drop a file, give it a name, and within seconds you have a CID and a Pinata gateway URL like https://gateway.pinata.cloud/ipfs/CID. For programmatic uploads, Pinata provides SDKs in multiple languages and a clean REST API. You can also configure a custom dedicated gateway under your own domain, which is what most production NFT projects do.

Once you have a CID from either service, verify it works from multiple gateways. Try https://ipfs.io/ipfs/CID, https://CID.ipfs.dweb.link, and https://cloudflare-ipfs.com/ipfs/CID. All three should serve the same content. If you ever see different content at the same CID from different gateways, something is very wrong, and you should report it. The whole point of content addressing is that the CID is the content.

Real Production Use Cases

IPFS is not a research project anymore. It powers significant production traffic, and the examples below are worth knowing because they show what IPFS is actually good at versus where it is overhyped.

Wikipedia mirror in Turkey: When Turkey blocked Wikipedia in 2017, the Wikimedia Foundation worked with the IPFS community to publish a full mirror of Turkish Wikipedia on IPFS. Users could access it through any IPFS gateway the government had not blocked. This remains the most cited demonstration of IPFS censorship resistance.

Brave Browser: Brave was the first major browser to ship native IPFS support, letting users resolve ipfs:// URLs through a public gateway or run a local Kubo node directly from the browser. This brought IPFS to tens of millions of users with no setup.

Audius: The decentralized music streaming platform stores all of its music on IPFS via its own content nodes. Artists upload, the platform pins, listeners stream. A real consumer application with millions of users and a tokenized creator economy.

OpenSea and NFT marketplaces: The majority of NFT metadata and media on Ethereum, Polygon, and Solana is stored on IPFS through pinning services. By volume of unique content stored, this is the largest single use case for IPFS.

dApp frontends: Uniswap, Aave, 1inch, and many other major DeFi protocols publish frontend builds to IPFS and pin them on multiple services. Users who care about censorship resistance can access these frontends directly via IPFS even if the team's domain is seized or DNS-poisoned.

Risks and Honest Limitations

IPFS is a powerful protocol, but it is not magic, and the marketing sometimes oversells what it actually provides. Here are the risks and limitations you should understand before betting a project on IPFS.

The first and biggest risk is pin reliability. Your content stays alive only as long as someone pins it. Free tiers often have storage and rate limits. If you exceed them and do not upgrade, pins can be removed. Plan for paid pinning or self-hosting if your project matters, and consider Filecoin deals for archival.

The second risk is gateway centralization. Most "IPFS users" today are HTTP users hitting a handful of gateways. If gateways consolidate further or face regulatory pressure, the practical decentralization story weakens. Mitigate by using multiple gateways and encouraging power users to run real nodes.

The third issue is privacy. IPFS is not anonymous. When you request a CID, your peer ID and IP are visible to peers, and anyone running a DHT node can see which CIDs are being requested. For sensitive content, IPFS alone is not enough; you need encryption or onion-routed transport.

The fourth issue is latency. Retrieval from cold storage can be slow, especially for poorly replicated CIDs. The DHT adds round trips and bitswap is not as optimized as a polished CDN. For high-traffic dynamic content, IPFS is not the right tool.

The fifth issue is the data permanence misconception. The CID is permanent in the sense that the same content always has the same address. But if no node hosts the content, the address resolves to nothing. Permanence is a feature of pinning and Filecoin deals, not of IPFS itself.

IPFS, Stablecoins, and Web3 Plumbing

One less obvious but important role IPFS plays in Web3 is as the storage layer for governance documents, terms of service, and risk parameter sets that need to be auditable and immutable. Major stablecoin issuers and DeFi protocols publish attestation documents, reserve reports, and governance proposals as IPFS CIDs referenced from their smart contracts. This gives token holders a tamper-proof historical record that does not depend on the issuer's web servers.

The same pattern shows up in DAO governance: proposal text and supporting documents are pinned to IPFS so the on-chain vote always references the exact content people were voting on. Tools like Snapshot and Tally support IPFS-pinned proposals natively. When you check a historical proposal on a blockchain explorer and click the description, you are typically loading a CID from IPFS.

Frequently Asked Questions

Conclusion

IPFS is one of the most important pieces of infrastructure to emerge from the broader decentralized computing movement of the last decade. By replacing location-based addressing with content-based addressing, it solved a problem that the web has had since its earliest days: links break, content disappears, and centralized servers create single points of failure. IPFS does not fix everything about the web, but it provides a powerful, working alternative for the parts of the internet that benefit most from immutability and resilience.

The honest summary is that IPFS works extremely well for static, addressable, long-lived content where integrity matters: NFT metadata, dApp frontends, archival documents, governance records, and decentralized publishing. It works less well for high-throughput dynamic content, private data without additional encryption, and use cases that need millisecond latency. The protocol is mature, the tooling is solid with Helia and Kubo, and the pinning services landscape is competitive enough that anyone can start uploading content within minutes.

The honest caveats are equally important. Gateway centralization quietly recenters a lot of traffic on a handful of operators. Pin reliability depends entirely on who is paying the bill. The marketing around "permanent storage" is misleading without Filecoin or robust pinning. If you understand these limitations, IPFS is a fantastic tool. If you do not, you can ship NFT collections that quietly rot, dApps that lose their frontends, and archives that vanish when nobody is looking. Use IPFS thoughtfully, pair it with Filecoin or professional pinning where durability matters, and you have one of the most powerful storage primitives of the modern Web3 stack.

Related Guides

• TON Storage Explained: Decentralized File Storage Guide (2026)
• What Is IPFS: Decentralized Storage, Content Addressing and Distributed Files (2026)
• What Is Infura: Web3 APIs, IPFS Access and MetaMask Infrastructure (2026)