IPFS Content Addressing vs. Location Addressing

Content addressing vs location addressing is not a minor technical detail, it is the actual design split between how IPFS works and how the web you already know works. An HTTP URL tells you where to ask for a file. An IPFS CID tells you what the file is, and nothing about where it lives. That single difference is what makes IPFS resistant to tampering and link rot, and it is also what makes pinning a required piece of the system rather than an optional convenience.

TL;DR:

• HTTP addresses are location-based: https://example.com/file.png names a server, and if that server goes down or the file moves, the link breaks
• IPFS addresses are content-based: a CID is derived from the file's own hash, so the same content always produces the same CID no matter who is hosting it
• Content addressing solves two real problems: tamper-evidence (any change to the content changes the CID) and link rot (the link stays valid as long as any peer still has the content, not just the original one)
• It creates one new problem in exchange: a CID says nothing about where the content is, so something still has to actually host it for the address to resolve to anything
• This is the exact gap pinning services exist to close. A valid CID with zero hosts is just an unreachable hash, and AIOZ Pin's job is making sure that never happens to files you care about

What Location Addressing Actually Means

An HTTP URL is an instruction, not a description: "go ask this specific server for whatever it currently has at this path." The server is free to change what lives there, rename it, or take it down entirely, and the URL keeps pointing at the same place regardless. That is exactly why link rot exists. A 2026 study is not needed to know this; anyone who has clicked an old link from a five-year-old article and hit a 404 has already run the experiment. The address was never a promise about the content, only about the location.

What Content Addressing Actually Means

A CID is the opposite kind of address. It is derived by hashing the content itself, specifically the root block of the file's Merkle DAG, so the address is a description of what the data is, not an instruction for where to find it. Add the exact same file from two different machines with the same settings and you get the exact same CID both times, because the hash only depends on the bytes, not on who is doing the hashing or where the result gets stored. Change a single byte anywhere in the file and the CID changes completely, because that change propagates up through every parent hash in the DAG. The mechanics of how that hashing and linking actually works are covered in the hub article for this series; what matters here is the consequence: the address and the data are mathematically the same thing.

The Two Real Problems This Solves

Two concrete benefits fall out of that design. First, tamper-evidence: if a CID resolves to content that does not hash back to that exact CID, something has been altered or corrupted, and any node can catch this locally without asking a trusted authority to vouch for it. Second, link permanence independent of the original host: because the address does not name a server, the same CID keeps working as long as any peer on the network still holds the content, not specifically the one that uploaded it first. A file mirrored across ten peers has ten independent paths to the same unbroken address. An HTTP link only ever has one.

The Problem It Creates: Discovery

Detaching the address from the location does not make location stop mattering, it just moves the question. A CID that resolves to nothing is useless no matter how mathematically sound the hash is. Somewhere, some peer has to actually be holding the blocks that CID points to, and something has to make it possible for other peers to find that holder, which is exactly what the DHT-and-Bitswap retrieval flow covered elsewhere in this series exists to do. Content addressing fixes the "is this the real file" question. It does not answer "does anyone currently have this file," and those are genuinely different questions.

Why "Anyone Can Host It" Doesn't Mean "Someone Will"

This is the gap that trips people up. IPFS's open design means any peer, anywhere, is technically capable of hosting any piece of content, and that is a real strength for censorship-resistance and mirroring. But capability is not the same as commitment. A file added from a laptop that gets closed an hour later has exactly one host, and once that host disconnects, the CID stops resolving for anyone, even though the address itself is still perfectly valid. Content addressing guarantees the integrity of a file forever. It says nothing about the availability of a file for longer than someone chooses to keep serving it.

This Is Why Pinning Exists

Pinning is the direct answer to that gap: an explicit, ongoing commitment that a specific peer will keep specific content available and refuse to garbage-collect it, so the DHT always has at least one real answer when someone asks who has a given CID. Without a pin, content addressing gives you a permanent, verifiable name for data that might not exist anywhere reachable next week. With a pin, the same address becomes something you can actually depend on. Content addressing is the promise about what; pinning is the promise about whether it's still there.

Where AIOZ Pin Fits In

AIOZ Pin exists entirely inside this gap. It does not change how CIDs are computed or how content addressing works, that is standard IPFS underneath. What it adds is the hosting commitment: pinned files stay online and replicated so the DHT has somewhere real to point, instead of depending on whichever machine happened to upload the file first staying online indefinitely. Premium gateways go a step further and skip the discovery question altogether for a request, since the gateway already is a known, dedicated host rather than something a client has to locate fresh on every fetch.

Frequently Asked Questions

What is the difference between content addressing and location addressing? Location addressing (HTTP URLs) names a server and path; the content can change without the address changing. Content addressing (IPFS CIDs) is derived from the content's own hash; the address changes if the content does, and stays the same across any host that has it.

Does content addressing prevent link rot? It prevents the specific cause of link rot that comes from a single server going down, since the same CID works from any host. It does not prevent link rot caused by nobody hosting the content at all.

If a CID is unique to its content, why isn't that enough to keep files available? Uniqueness only guarantees the address is trustworthy, not that anyone is currently serving it. A CID with no active host is a valid but unreachable address.

Is content addressing more secure than location addressing? For tamper detection, yes: any modification changes the CID, which any node can verify locally. It does not make the underlying data more available; that depends entirely on hosting.

Why does IPFS need pinning if content addressing already works? Content addressing solves what a valid address looks like. Pinning solves whether that address actually resolves to something, by committing a peer to keep serving the content instead of letting it disappear once the original uploader goes offline.

Does AIOZ Pin change how CIDs work? No. CIDs are computed the same way with or without AIOZ Pin. What AIOZ Pin adds is the hosting guarantee that keeps a CID resolvable over time.

Related Reading

• How IPFS Really Works: Merkle DAGs, Chunking, and Content Routing Explained - the mechanics behind how a CID gets derived in the first place
• How IPFS Finds and Retrieves Your Files: DHT Provider Records and Bitswap Explained - how the network actually answers "who has this CID"
• How AIOZ Pin Actually Keeps Your Files Online: Replication, CIDs, and Proof-of-Storage - the product-level mechanism that closes this gap
• Content Moderation on IPFS: What Actually Happens - the direct practical consequence of this article's core distinction
• What Is IPFS? The Ultimate Guide to Decentralized Storage - the concept-level introduction this article builds on

References

• IPFS Docs: Content Addressing
• IPFS Docs: The Lifecycle of Data in IPFS