Multihash
Every CID contains a multihash. If you ever need to validate that a fetched IPFS payload matches its CID, swap in a different hash, or implement a custom indexer, you read and emit multihash bytes directly.
What It Defines
Self-describing hash format that prefixes a digest with its hash function code and length, encoded as `<varint hash-code><varint length><digest>`. The whole point: a single byte string identifies both the hash algorithm (sha2-256, blake3, blake2b, sha3-512, …) and the digest, so consumers can safely upgrade hash functions without breaking existing addresses. Multihash is the digest portion embedded inside every CID and the foundation for hash agility across IPFS, IPLD, libp2p, and Filecoin.
Canonical (Normative)
Convenient (Practical)
Related References
Open community of implementers (Protocol Labs, Shipyard, Boost, Helia, Kubo, and others) that maintains the InterPlanetary File System spec family at specs.ipfs.tech. Publishes content-addressing primitives (CID, Multihash, Multibase, Multiaddr), the IPLD data model, naming systems (IPNS, DNSLink), and the HTTP Gateway specs (Path, Subdomain, Trustless, DNSLink) that bridge content-addressed storage to ordinary browsers.
Related Specs
Every DNSLink record, IPFS gateway URL, IPNS publish, and Filecoin deal references content by CID. If you do not understand what the bytes after `/ipfs/` mean, you cannot debug deploy/cache issues, validate signed manifests, or design content-addressed pipelines.
Multibase is the reason CIDv1 strings are DNS-safe lowercase base32 and can therefore appear in subdomain gateway hostnames like `bafy….ipfs.example.com`. If you build URL routers or parsers that touch CIDs, you encode and decode through multibase.