What Is IPFS?

In brief

• IPFS stands for InterPlanetary File System and refers to open protocols, implementations and participating networks for content-addressed data.
• A CID identifies a block or the root of a data structure using a hash plus information needed to interpret that identifier.
• Large files and directories are usually chunked and linked as a Merkle directed acyclic graph, so a file’s CID is not necessarily its ordinary file checksum.
• Routing finds providers; transfer protocols or gateways retrieve the blocks; CID verification checks integrity.
• Content remains available only while at least one reachable provider retains and serves all required blocks.
• Pinning protects selected content from a node’s garbage collection. A pinning service operates storage infrastructure; IPFS itself is not the provider.
• HTTP gateways improve compatibility but can add availability, privacy and trust dependencies.
• An ipfs:// NFT metadata URI makes content tampering detectable; it does not guarantee persistence or transfer copyright.

Content addressing instead of host addressing

Consider two identifiers:

• https://example.com/images/cat.jpg tells a client to ask a named host for a path.
• ipfs://<cid>/cat.jpg identifies a content-addressed root and a path beneath it.

The HTTP host can change what it serves at a path. An immutable CID instead commits to a particular block or graph of blocks. If retrieved data does not match the CID, an IPFS implementation is expected to reject it.

This gives IPFS self-certifying addressability: clients can check the mapping between an identifier and content without asking the original publisher to vouch for every copy. It does not prove that the publisher is trustworthy or that the content is safe. A correctly addressed malicious file is still malicious.

What is inside a CID?

A CID is more than a bare SHA-256 checksum. Depending on its version, it can encode:

• the CID version;
• a multicodec indicating how the referenced block should be interpreted;
• a multihash identifying the hash function and digest; and
• a multibase prefix in the textual representation.

For a small raw block, the digest may directly hash the file bytes. Larger files are commonly chunked, encoded and arranged as a UnixFS/IPLD Merkle DAG. The root CID then commits to the root block, which links to child blocks. It will not generally equal a conventional checksum of the whole file.

The same file bytes can also receive different CIDs if software uses different chunk sizes, DAG layouts, codecs, hash functions or CID versions. With the same import settings, a content change produces a different root CID. Reproducible CIDs therefore require agreement on how data is encoded, not merely possession of the same file.

Addressing, routing and transfer are separate jobs

Knowing a CID does not tell a node which peer currently has the blocks. IPFS implementations combine several subsystems:

1. Representation: IPLD and formats such as UnixFS organize content-addressed blocks and links.
2. Routing: a distributed hash table, connected peers, delegated HTTP routers or local discovery can help locate providers.
3. Transfer: Bitswap, HTTP gateways, Graphsync or even offline CAR files can move content.
4. Verification: the receiving implementation checks blocks against their CIDs and follows verified links through the graph.

This separation is why “IPFS is a peer-to-peer network” is incomplete. An implementation may use multiple transports and routing services while preserving content verification at the endpoint.

A provider record is not a backup. It is routing information indicating that a peer claims to serve content. Retrieval can still fail because the peer went offline, stopped retaining blocks, is unreachable or does not have every block in the graph.

Caching, pinning and persistence

Nodes may cache blocks they retrieve. Because storage is finite, a node can later garbage-collect unprotected cached data. Popularity may create more temporary copies, but there is no protocol rule that every requested item remains cached.

A local pin tells a node to protect specified content and the reachable blocks it needs from garbage collection. Adding a file through common node tools may pin it locally, but that protects only the storage on that node. If the machine disappears, so can that copy.

For durable availability, a publisher can:

• operate one or more always-on IPFS nodes;
• use independent pinning services;
• distribute copies to partners or community nodes;
• keep verifiable CAR archives and restore them when needed; or
• arrange storage through a separate system such as Filecoin.

These choices create different payment, retention and operator assumptions. IPFS guarantees verifiable addressing when content is retrieved; it does not guarantee that someone will pay to retain it.

Gateways: convenient, but not all equivalent

Most browsers do not retrieve ipfs:// resources natively. An HTTP gateway translates a request such as:

https://gateway.example/ipfs/<cid>/path

into IPFS retrieval or serves content it already has. If that gateway is down or blocks a request, an IPFS-aware client can try another provider while keeping the same CID.

There are important trust distinctions:

• A traditional gateway verifies content itself, but an ordinary browser may trust the gateway’s deserialized HTTP response.
• A trustless gateway can return verifiable blocks or proofs that an IPFS-capable client checks locally.
• A recursive gateway searches other providers; a non-recursive gateway serves only its own content or configured backend.

Gateway URL style also matters. Path gateways place many sites under one browser origin and should not host applications that require origin isolation. Subdomain gateways place the CID in the hostname and provide a separate origin per content root.

Using a single public gateway creates a centralized access dependency, even though the CID remains portable. Applications should avoid treating one gateway URL as the only durable identifier.

Immutable CIDs and mutable names

Changing content normally changes its CID. Applications that need a stable name pointing to the latest version can use a mutable layer such as IPNS or DNSLink. That reintroduces an update authority: the holder of the relevant key or DNS control can change which CID the name resolves to.

This is not a contradiction. The mutable name selects a version, while the resolved CID still identifies immutable content. Users who need a permanent reference should record the CID, not only the mutable name.

IPFS, NFTs and smart contracts

An NFT contract often stores or returns a metadata URI. If it uses:

ipfs://<metadata-cid>/metadata.json

the metadata JSON is content-addressed. If that JSON references an image with another ipfs:// URI, the image is independently content-addressed too. Anyone retrieving different bytes under those immutable CIDs can detect the mismatch.

Several caveats remain:

• Somebody must retain all metadata and media blocks.
• A contract may expose a mutable base URI or permit metadata updates.
• A gateway can be unavailable even when another provider has the data.
• The token records onchain ownership under its contract rules; IPFS does not grant copyright, enforce royalties or prove authorship.

The live NFTs article explains token ownership and metadata at a broader level. The Smart contracts article explains why contracts commonly store compact identifiers rather than large media files.

Privacy and safety

IPFS does not encrypt content or provide access control by default. Peers, gateways and routing services may observe requested CIDs, network addresses or provider activity. If confidentiality matters, encrypt data before publication and manage keys separately.

A CID is not necessarily “guessable” at random, but known or predictable source material can be imported using common settings to derive candidate CIDs. Treat the public IPFS network as a public distribution system, not a private drive.

Content addressing verifies integrity, not legality, authenticity or harmlessness. Users still need trusted signatures, provenance and safe file handling where those properties matter.

What IPFS is not

• It is not Ethereum, Bitcoin or a consensus ledger.
• It does not place a file “onchain.”
• It is not an incentive layer or storage contract.
• It does not automatically replicate every file.
• It is not a replacement for a blockchain node or historical archive.
• It does not make mutable information immutable unless a specific CID is retained.