InterPlanetary File System (IPFS) CID

An InterPlanetary File System (IPFS) Content Identifier (CID) is a self-describing cryptographic hash that uniquely and permanently identifies content stored on the IPFS distributed network. Unlike traditional location-based addresses (like URLs), which point to where data is stored, a CID is a content-addressed identifier derived from the data itself. This means that any piece of content—whether a document, image, or dataset—will always generate the same CID, allowing for secure, verifiable, and deduplicated storage across the peer-to-peer network.

The structure of a CID is highly versatile, encoding multiple pieces of information within its string representation. It specifies the cryptographic hash function used (e.g., SHA-256), the codec describing the data format (e.g., dag-pb for IPFS files, dag-cbor for structured data), and a multibase prefix indicating the encoding (like b for base32). This self-contained design, often seen as a string starting with bafy..., ensures that the CID can be interpreted correctly by any system without external context, a principle known as content addressing.

In blockchain and Web3 applications, CIDs are fundamental for linking to off-chain data in a trust-minimized way. A smart contract or an NFT's metadata often stores only a CID, which points to the actual JSON file or media asset stored on IPFS. This creates a permanent, immutable link; if the underlying data changes, its CID changes entirely, providing a clear audit trail. This mechanism is crucial for data integrity, persistence, and enabling decentralized applications (dApps) to reference data without relying on centralized servers.

From a technical perspective, generating a CID involves constructing a Merkle DAG (Directed Acyclic Graph) representation of the data and then hashing its root node. Large files are typically split into smaller blocks, each with its own hash, which are then linked together. This architecture enables efficient deduplication—if two users add the same file, IPFS stores it only once—and supports partial sharing, where peers can fetch different pieces of the same file from multiple sources simultaneously.

The evolution of the CID specification, notably from CIDv0 to the more flexible CIDv1, has increased its interoperability across different decentralized protocols. CIDs are not exclusive to IPFS; they are a core component of the broader IPLD (InterPlanetary Linked Data) stack and are used by systems like Filecoin for storage deals and libp2p for peer and content routing. This universality makes the CID a foundational primitive for the decentralized web.

An InterPlanetary File System Content Identifier (IPFS CID) is a self-describing content-addressed identifier that uniquely and immutably represents any piece of data on the IPFS network. Unlike location-based addresses (URLs), which point to where data is stored, a CID is derived from the content itself using cryptographic hashing. This means that identical data will always produce the same CID, enabling deduplication and verifiable integrity. The CID contains a multihash, which specifies the cryptographic hash function used (e.g., SHA-256) and the hash digest, along with other metadata about the content's encoding format.

The structure of a CID is versioned and extensible. CIDv0 is the original format, recognizable as a Base58-encoded SHA-256 hash starting with 'Qm'. The more advanced CIDv1 supports multiple hash functions, codecs (like dag-pb for files or dag-cbor for structured data), and a flexible binary format that can be represented in various bases (Base32, Base58, etc.). This versioning allows the system to evolve while maintaining backward compatibility. The core innovation is that the CID itself tells the network everything needed to locate and verify the content, independent of any specific server or location.

When you add a file to IPFS, the protocol segments it into blocks, hashes each block, and links them in a Merkle Directed Acyclic Graph (DAG) structure. The root hash of this DAG becomes the file's CID. To retrieve the data, a node requests the content by its CID from the network. Other nodes that have pinned the data can provide the blocks. The requesting node verifies the integrity of each received block by recalculating its hash and ensuring it matches the hash referenced in the CID, guaranteeing the content is authentic and unaltered.

CIDv0 and CIDv1 are distinct versions of Content Identifiers (CIDs), the core addressing system for content in IPFS. A CID is a self-describing content-addressed identifier, but the two versions differ in their encoding format, flexibility, and future-proofing. CIDv0 is the original, legacy format, recognizable as a Base58-encoded hash starting with Qm. CIDv1 is the modern, extensible standard that supports multiple bases, hash functions, and codecs through a structured binary format defined in the multiformats project.

The primary technical distinction lies in their structure. A CIDv0 is essentially a multihash (a self-describing hash) encoded in Base58. It is inflexible, implicitly using the SHA-256 hash function and the DagProtobuf codec. In contrast, a CIDv1 is a fully self-describing binary structure with explicit version prefix, codec identifier, multihash, and optional metadata. This structure allows CIDv1 to support a wide range of content types (e.g., raw, dag-cbor, dag-json) and cryptographic hash functions (e.g., sha2-256, sha3-512, blake3) beyond the limitations of v0.

For compatibility, CIDv1 can be converted to a CIDv0-equivalent string only under specific conditions: the multihash must be SHA-256, the codec must be DagProtobuf, and it must be encoded in Base58. However, the reverse is not true; a CIDv1 representation of any content will always be different from its CIDv0. Modern IPFS tooling and APIs primarily generate CIDv1, though they maintain backward compatibility by accepting and resolving CIDv0. The shift to v1 is critical for the ecosystem's evolution, enabling support for new data structures and ensuring interoperability across different decentralized networks like IPFS, Filecoin, and IPLD.

An InterPlanetary File System (IPFS) Content Identifier (CID) is a self-describing cryptographic hash that uniquely and permanently identifies a piece of content stored on the decentralized IPFS network, serving as the foundational data pointer for Non-Fungible Token (NFT) metadata and digital assets. Unlike a traditional URL that points to a location, a CID points to content itself, ensuring that the data referenced by an NFT—be it a JPEG, animation, or a JSON metadata file—is immutable and verifiable. This shift from location-based to content-based addressing is what underpins the concept of true digital ownership and provenance in Web3.

In a typical NFT's architecture, the on-chain token contract contains a tokenURI that resolves to an IPFS CID, not a centralized web server address. This CID points to a JSON metadata file that itself contains descriptive attributes and, crucially, another IPFS CID linking to the actual image or media file. This creates a verifiable chain of hashes: the on-chain token points to a metadata CID, which in turn points to an asset CID. Any alteration to the underlying image or metadata would generate a completely different CID, breaking the link and proving the data has been tampered with, thus guaranteeing the NFT's provenance and authenticity.

The robustness of this system relies on content addressing and decentralized storage. When you "pin" a file to IPFS, it is split into chunks, hashed, and given a CID. The network's participants store and serve these chunks. As long as at least one node on the IPFS network hosts the data associated with a CID, it remains accessible. This makes NFTs more resilient than those relying on traditional web hosting, which are vulnerable to link rot if a company's server goes offline. Services like Filecoin and Pinata provide incentivized, persistent storage layers to ensure CIDs remain retrievable long-term.

For developers and collectors, verifying an NFT's integrity involves checking the CIDs in its metadata. Tools can fetch the metadata from the tokenURI, hash the linked image file, and compare it to the CID stored in the metadata. A match confirms the asset is authentic. This process highlights a critical best practice: NFT creators should "hash the image first"—generating the asset's CID before creating the metadata file that references it—to ensure the entire data chain is immutable from the point of minting. This prevents mismatches and preserves the intended artwork for the token's lifetime.