IPFS Specifications
IPFS
Content-addressed web infrastructure — each primitive (CID, gateway, IPNS) has its own spec page in a structured index.
What It Is
InterPlanetary File System spec family: CID, Multihash, Multibase, IPLD, IPNS, DNSLink, and HTTP Gateway specs at specs.ipfs.tech.
Taxonomy
By spec area: Content addressing · Naming · HTTP gateways · Data models
Top-Level Categories
Master Catalog
Sub-Indexes & Guides
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.
View all bodies →Curated specs from IPFS
DNSLink is how you give an IPFS/IPNS deployment a stable human URL like `mysite.example.com` while the underlying CID changes every release. If you ever host static sites, agent artifacts, or signed manifests on IPFS and want a normal-looking domain, this is the spec.
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.
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.
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.
If you do not want to update a DNS TXT record on every deploy, point DNSLink at IPNS and republish the IPNS record to the new CID. IPNS is the mutable pointer that makes content-addressed storage usable for evolving sites.
Path gateways are how a regular browser without IPFS support fetches content-addressed data. Knowing the spec is required to operate a self-hosted gateway, debug 404/range/CORS issues, or build clients that fall back from native IPFS to HTTP gateways.
Path gateways break the web origin model — every CID shares the gateway origin. Subdomain gateways are the production-correct choice for hosting independent sites. This is also the only model that makes single-page apps with cookies and Service Workers function on a public gateway.
DNSLink alone tells nobody how a browser request actually turns into a served HTML page. The DNSLink Gateway spec is the contract between your DNS records and the gateway that browsers hit — required reading if you operate a custom gateway for user sites under a wildcard like `*.dial.wtf`.