IPFS Hash (CID)

An IPFS Hash, formally known as a Content Identifier (CID), is a unique cryptographic fingerprint that permanently identifies a piece of content—such as a file, directory, or data block—on the InterPlanetary File System (IPFS). Unlike location-based addresses (e.g., URLs), which point to where data is stored, a CID is a content-addressed identifier derived from the content itself using a cryptographic hash function. This means the same content will always produce the same CID, enabling deduplication, tamper-proof verification, and permanent, location-independent addressing across a decentralized network.

The structure of a modern CID is self-describing, containing several key components within its encoded string. It specifies the multihash (the actual hash digest and the algorithm used, like SHA-256), the multicodec (the format of the data, e.g., raw bytes, dag-pb for IPFS objects, or dag-cbor), and the multibase prefix (the encoding, such as base58btc or base32, for readability). For example, a CIDv1 like bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi tells the network everything needed to fetch and interpret the content. This self-contained design ensures CIDs remain usable even as hash algorithms evolve.

In practice, when a file is added to IPFS, it is split into blocks, each receiving its own CID. These blocks are then organized into a Merkle Directed Acyclic Graph (DAG) structure, with a root CID representing the entire file or directory. This architecture enables powerful features: deduplication (identical blocks are stored once), tamper-evidence (any change alters the CID), and efficient versioning. CIDs are fundamental to the decentralized web, forming the backbone of protocols like IPFS and Filecoin, and are widely used in blockchain applications for storing NFTs, static website assets, and immutable data.

A Content Identifier (CID) is a self-describing content-addressed identifier. It is generated by applying a cryptographic hash function (like SHA-256) to the content's data, creating a unique, fixed-size string. This process, known as content addressing, means the CID is derived directly from the data itself. If the data changes even by a single bit, the resulting CID will be completely different. This ensures immutability and verifiability, as anyone can hash the data to confirm it matches the CID.

The structure of a modern CID (version 1, or CIDv1) is more than just a hash. It is a multiformat string that encodes several pieces of metadata in a self-describing way using Multicodec, Multihash, and Multibase prefixes. For example, a CID like bafybeigdyr... tells you the hash function used (SHA2-256), the length of the hash, and the base encoding (Base32). This layered structure allows the IPFS protocol to evolve, supporting new hash functions and data formats without breaking compatibility.

When you request content by its CID, the IPFS network uses a Distributed Hash Table (DHT) to locate network peers who have announced they are storing the data blocks associated with that fingerprint. The system retrieves and reassembles these blocks. This mechanism decouples content from location; instead of asking "where is the file?" (like https://server.com/file.jpg), you ask "who has the data matching this hash?" This makes content resilient, as it can be retrieved from any node that has a copy, not just a single server.

A Content Identifier (CID) is a self-describing content-addressed identifier for data stored on the InterPlanetary File System (IPFS). The evolution from CIDv0 to CIDv1 represents a fundamental shift towards a more flexible, future-proof, and multi-protocol addressing scheme. CIDv0 is the original format, essentially a Base58-encoded SHA-256 multihash (e.g., Qm...), while CIDv1 is an extensible format that includes a version prefix, multicodec identifier, and multihash within a binary structure, typically represented as a CIDv1 string like bafybeig....

The primary technical distinction lies in their structure and encoding. CIDv0 is a legacy format that is implicitly version 0 and uses the dag-pb multicodec for IPLD data. It is restricted to the SHA-256 hash function and Base58 encoding, making it recognizable by its Qm prefix. In contrast, CIDv1 is explicitly versioned, includes a field to specify the content type (e.g., dag-cbor, raw), and can accommodate any hash function defined in the multihash table. This allows CIDv1 to represent a wider array of data structures and cryptographic commitments beyond IPFS's original scope.

A key practical difference is CIDv1's support for multiple textual representations. While CIDv0 only exists in Base58, a CIDv1 can be represented in various bases defined by the Multibase prefix, such as Base32 (b...) for case-insensitive environments or Base64. The common bafy... string is a Base32-encoded CIDv1. This flexibility makes CIDv1 more suitable for web applications, DNS, and filenames. Importantly, the underlying content address is identical for both versions when pointing to the same data; they are different encodings of the same cryptographic hash.

For developers, the choice is increasingly straightforward: CIDv1 is the modern standard. Most contemporary IPFS tooling and APIs, including the JavaScript (ipfs-core) and Go (kubo) implementations, generate CIDv1 by default. While the network remains fully compatible with CIDv0 for backward compatibility, new projects should adopt CIDv1 for its extensibility. A CIDv0 can be losslessly converted to its CIDv1 equivalent, but the reverse is not universally true, as CIDv1 can express constructs that CIDv0 cannot, such as content using the SHA3-256 hash or the dag-json codec.

Understanding the version difference is crucial for interoperability across the decentralized web stack. Protocols like IPLD (InterPlanetary Linked Data), Filecoin, and libp2p rely on CIDv1's ability to precisely describe the data being referenced. The version, multicodec, and multihash components work together to ensure that data is not only located but also correctly interpreted upon retrieval, forming the backbone of content-addressed verifiability in Web3 systems.