IPFS CID (Content Identifier)

An IPFS Content Identifier (CID) is a self-describing content-addressed identifier that uniquely and permanently points to a piece of data on the InterPlanetary File System. Unlike location-based addressing (e.g., a URL), which tells you where to find data, a CID is derived from the content's cryptographic hash, telling you what the data is. This creates immutable links; if the content changes, its CID changes completely, guaranteeing data integrity and enabling verifiable, permanent references.

A CID is a multiformat string, typically starting with Qm for CIDv0 or b for CIDv1, which encodes two critical pieces of information: the cryptographic hash of the content (e.g., SHA2-256) and the codec, which specifies how to interpret the underlying data (e.g., dag-pb for IPFS data structures or raw for raw bytes). This self-describing nature allows systems to understand how to process the data without external context. CIDs are the foundational building block for content-addressed storage and verifiable data structures across decentralized networks.

In practice, developers interact with CIDs when pinning files, retrieving data via ipfs get <CID>, or referencing assets in smart contracts and NFTs. For example, an NFT's metadata JSON file is often stored on IPFS, and its CID is recorded on-chain, creating a permanent, tamper-proof link to the asset's data. This architecture decouples data storage from specific servers, enabling persistent, decentralized access as long as at least one node on the IPFS network hosts the content referenced by the CID.

An IPFS CID (Content Identifier) is a unique label derived from the cryptographic hash of the content itself, ensuring that identical data produces the same CID anywhere in the network. This process, known as content addressing, contrasts with traditional location addressing (like URLs), which points to a specific server. The CID is the foundational mechanism that enables IPFS's decentralized, peer-to-peer file sharing by allowing users to retrieve content from any node that possesses it, verified by its immutable hash.

A CID is not a single hash but a structured format that encodes several pieces of information. The most common version, CIDv1, includes a multicodec prefix (indicating the data format, e.g., dag-pb for IPFS files), a multihash (the actual cryptographic digest like SHA2-256), and optionally a multibase prefix (specifying the encoding, like base32). This self-describing structure allows systems to interpret the CID without external context. For example, the CID bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi tells you it's a SHA2-256 hash encoded in base32.

The generation of a CID begins with the InterPlanetary Linked Data (IPLD) model, where data is structured into Merkle DAGs (Directed Acyclic Graphs). When a file is added to IPFS, it is chunked, and each chunk is hashed. These hashes are then organized into a tree structure, with the root hash becoming the file's CID. This architecture enables efficient deduplication—if two files share identical chunks, those chunks are stored only once, referenced by the same hash, optimizing storage across the network.

A critical property of CIDs is their immutability: the identifier is inextricably linked to the content's bits. If the data changes by even one byte, its cryptographic hash—and therefore its CID—changes completely. This guarantees integrity, as anyone fetching data with a specific CID can verify it matches the expected hash. However, this also means updating content requires generating and distributing a new CID, which is why mutable pointers like IPNS (InterPlanetary Name System) or DNSLink are often layered on top for human-readable, updable references.

In practice, developers interact with CIDs through IPFS client libraries or CLI commands like ipfs add. The system handles the complex hashing and DAG construction automatically. Understanding CIDs is essential for building decentralized applications (dApps), implementing secure data provenance, and leveraging the core promise of IPFS: permanent, verifiable, and location-independent access to information.

An IPFS CID (Content Identifier) is a self-describing content-addressed identifier composed of a multicodec prefix, a multihash, and an optional multibase prefix, which together uniquely and verifiably point to a piece of content on the decentralized web. The CID specification, defined in RFC 2391, ensures that the identifier itself contains all the information needed to interpret the data it references, including the format of the content and the cryptographic hash function used. This design makes CIDs immutable, portable, and future-proof, as they are not tied to a specific location or protocol.

The core of a CID is its multihash, a self-describing hash digest that specifies the hash function (e.g., sha2-256) and the digest length. This is prefixed by a multicodec identifier that indicates the format of the target data, such as dag-pb for IPLD Protobuf nodes or raw for raw bytes. Finally, a multibase prefix (like b for base32) can be added to the entire string, encoding it for safe use in various contexts like URLs or filenames. A CIDv1 in its textual form typically appears as bafybeig... where the b denotes base32 encoding.

CIDs exist in two primary versions: CIDv0 and CIDv1. CIDv0 is the legacy format, starting with Qm, which implicitly assumes SHA-256 hashing and Base58BTC encoding. CIDv1 is the extensible, self-describing format that explicitly includes the multicodec and can use any multibase encoding. The migration to CIDv1 was crucial for supporting diverse hash functions (like blake3) and data formats beyond the original IPFS Merkle DAG, enabling broader interoperability across content-addressed systems.

Under the hood, a CID is a binary structure that can be serialized using CID multicodecs like dag-cbor or dag-pb. When developers work with CIDs programmatically—using libraries such as multiformats in JavaScript or Go—they parse this binary structure to extract the hash, verify data integrity, and resolve the content. This technical anatomy is what allows a single CID to reliably and permanently identify the same content across different networks, storage systems, and applications, forming the backbone of verifiable data exchange.