The InterPlanetary File System (IPFS) is an open-source, peer-to-peer protocol for storing and sharing files. Instead of fetching a file from a particular server, as a normal web address does, IPFS asks the network for a file with a particular fingerprint. Any computer holding a copy can supply it, and the requester can check that the copy is exactly what was asked for.
IPFS was designed by Juan Benet, who described it in a 2014 paper and founded Protocol Labs to develop it. It is not a blockchain and has no token of its own, but it is widely used alongside blockchains to hold data that is too large or too costly to put on-chain, such as images for non-fungible tokens (NFTs) and the front ends of decentralised applications.
IPFS in plain terms
A normal web link works like a street address: it tells you where to go, not what you will find. If the shop moves or changes its stock, the address still works but the content is different, or gone.
IPFS works more like a library catalogue number that describes the exact edition of a book. You ask "who has this exact book?", and any nearby reader with a copy can hand it over. You can check it is the right edition by comparing the number. If the book is changed in any way, it gets a new number, so nobody can quietly swap it. The catch is that someone must keep a copy on the shelf, or the book can no longer be found.
How IPFS works
- Content addressing. Each piece of data is identified by a content identifier (CID) derived from a cryptographic hash of its contents. Change one byte and the CID changes.
- Chunking and linking. Large files are split into blocks linked together in a structure based on a Merkle tree (a Merkle DAG), so identical chunks are stored once and partial downloads can be checked.
- Finding providers. A distributed hash table, spread across participating nodes, records which peers hold which CIDs.
- Exchanging blocks. Peers trade blocks directly, and the receiver checks each one against its hash.
- Gateways. HTTP gateways let ordinary browsers fetch IPFS content through a normal web address, at the cost of trusting the gateway operator.
IPFS also offers a naming system that points a fixed name to changing content. Blockchain naming services such as the Ethereum Name Service (ENS) can store an IPFS content hash for a domain, so a website can be served without a single host.
Uses with blockchains
- NFT metadata and media. Token standards such as ERC-721 and ERC-1155 store a link to metadata rather than the image itself. Pointing that link at an
ipfs://address means the content cannot be swapped later without changing the link, unlike a link to an ordinary web server the creator controls. - Application front ends. Teams host the web interface of a DeFi protocol on IPFS so it stays reachable if a company's servers go down.
- Off-chain data for contracts. A smart contract can store only a CID, keeping fees low while still committing to the exact content. This is a common pattern in the off-chain layer of Web3 applications.
- Censorship resistance. In May 2017, after Turkey blocked Wikipedia, the IPFS project published a copy of Turkish Wikipedia on the network to show that content could stay reachable without a central host.
IPFS and Filecoin
IPFS alone does not pay anyone to keep data. Data survives only while at least one node chooses to store ("pin") it, often through a paid pinning service. Protocol Labs developed Filecoin (FIL) as a separate incentive layer: a blockchain on which storage providers are paid to keep data and must regularly prove they still hold it. Filecoin's main network launched in October 2020. Many storage services pin data on IPFS and back it up with Filecoin deals.
Limitations
- Not automatically permanent. Unpinned content disappears when the last copy is deleted, so NFTs that rely on unpinned IPFS files can still lose their images.
- Not private by default. Anyone who knows a CID can request the data, so sensitive files must be encrypted first, typically using standard cryptography.
- Hard to remove. Once others have copied content, the original publisher cannot force its deletion, which creates problems for illegal material and data-protection requests.
- Gateway dependence. Many users reach IPFS through a few public gateways, which brings back some of the central points of failure IPFS was meant to avoid.
- Performance. Finding rarely requested content across the network can be slower than downloading from a content delivery network.