What Is Content Addressing? IPFS vs Location Addressing

Content addressing is a way of naming data by a cryptographic hash of the data, instead of by the server that stores it. In IPFS, that name is a CID. An HTTP URL tells you where to ask. A CID tells you what you'll get, and lets you check it.

TL;DR:

• Location addressing (HTTP) names a server and a path. If the server goes down or the file changes, the link breaks or silently serves different bytes.
• Content addressing (IPFS) derives the address from the content's hash. The same content with the same settings always gets the same CID, wherever it's stored.
• You get tamper evidence and links that don't depend on one host. You also get a new problem: a CID doesn't say who has the data.
• Pinning closes that gap by committing a node to keep the blocks. That's the job AIOZ Pin does.

Updated Oct 19, 2026: new title and definition-first opening, a side-by-side diagram, a worked CID example from the IPFS docs, and a section on pinning a CID with AIOZ Pin. Updated Oct 22, 2026: merged our separate post IPFS Immutability: Why You Can't Edit a File in Place into this guide.

What is location addressing?

Location addressing is how the web you already use works. A URL such as https://example.com/cat.jpg is an instruction: ask this server for whatever it has at this path. DNS turns the name into an IP address, and that one machine answers.

Nothing ties the URL to the bytes. The owner can replace cat.jpg with a different picture, and your link still "works." They can move it or shut the server down, and your link returns a 404. You've seen this every time an old article links somewhere dead. The address only ever promised a place, never the content.

How does content addressing work in IPFS?

IPFS splits a file into blocks, hashes each block, and links the blocks into a Merkle DAG. The hash of the root block, wrapped with a little metadata, is the file's CID. The IPFS docs put it simply: a CID "doesn't indicate where the content is stored, but it forms a kind of address based on the content itself."

Two rules follow from that, and the IPFS docs state both. Any difference in the content produces a different CID. And the same content added to two nodes with the same settings produces the same CID. Change one byte anywhere, and the change ripples up through every parent hash to the root.

A CID isn't a plain file hash, though. It also carries the hash function (multihash), the data format (multicodec), and, in string form, the encoding (multibase). That's why the CID of a file never matches its SHA-256 checksum. The IPFS docs show this with the Ubuntu 20.04.1 desktop ISO. Its published checksum starts b45165ed, yet adding it gives a CID whose digest starts 0E7071C5:

$ ipfs add ubuntu-20.04.1-desktop-amd64.iso
added QmPK1s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB ubuntu-20.04.1-desktop-amd64.iso

That output is quoted from the IPFS docs. We didn't run it here, since this machine has no IPFS binary. Settings matter too: CID version, chunk size, and raw leaves all change the result. Our CID anatomy guide decodes each part, and the chunking guide explains how block boundaries feed into the hash.

What problems does content addressing solve?

The first is tamper evidence. When your node fetches blocks, it hashes them and compares the result with the CID you asked for. If they don't match, the data was altered or corrupted, and your node knows without trusting anyone. That's why a gateway can be "trustless": you verify what it sends.

The second is that links stop depending on one host. The CID doesn't name a server, so any peer holding the blocks can serve them. A file held by ten peers has ten paths to the same address, while an HTTP link has one. Deduplication comes along for free, because identical blocks get identical hashes and only need storing once.

Why can't you edit a file in place on IPFS?

Immutability is the flip side of content addressing. Because the CID is computed from the bytes, you can't change the bytes and keep the address. The IPFS immutability docs say it directly: once a file is added, its content "cannot be changed without altering the content identifier (CID) of the file."

So an edit never touches the old data. It builds a new DAG next to it. The docs use two leaf blocks, "hello" and "world", joined under a root:

Block B isn't edited. You get a new leaf D and a new root E, while C still points at the original. Block A appears in both versions because identical content always hashes to the same CID, so the unchanged part doesn't need a new block. Both versions stay retrievable for as long as someone pins each one, and nothing is overwritten.

That is what makes a CID safe to put inside an NFT's token URI: the reference can't quietly start serving different metadata. It also creates a practical problem for anything meant to update, like a website, because its CID changes on every edit. The fix is a mutable pointer on top: IPNS names or a DNSLink record that you update to the newest CID, so your visitors keep one stable address.

On AIOZ Pin this shows up in your pin list. Re-uploading an edited file through POST /api/pinning returns a new CID and creates a new pin. The old pin stays, and keeps counting toward your storage and pinned-file totals, until you remove it with DELETE /api/pinning/unpin/:pinId (Pinning API docs).

The problem it creates: discovery

Taking the location out of the address doesn't make location stop mattering. It moves the question. Your node still has to find a peer that holds the blocks, and IPFS answers that with the DHT, which maps CIDs to providers, and Bitswap, which moves the blocks. How IPFS finds your files covers both.

So content addressing answers "is this the right file?" It doesn't answer "does anyone have this file right now?" Those are different questions, and the second one is where most IPFS links fail.

Why "anyone can host it" doesn't mean "someone will"

Any peer can host any CID, which helps mirroring and makes takedowns hard. But being able to host isn't a commitment to host. Add a file from your laptop and close the lid an hour later, and that file had exactly one host. Once it disconnects, the CID stops resolving for everyone, even though the address is still valid.

Your own node can also drop the data. IPFS nodes run garbage collection and delete blocks nobody marked as important. Content addressing guarantees that a CID always means the same bytes. It guarantees nothing about whether those bytes stay reachable. Our garbage collection guide shows when blocks get removed.

How AIOZ Pin keeps a CID resolvable

Pinning is the commitment content addressing lacks. A pin tells a node to keep certain blocks and skip them during garbage collection, so the DHT always has a real provider to return. AIOZ Pin doesn't change how CIDs are computed. A file pinned with us has the same CID it would have anywhere, so your links stay portable.

You can pin in two ways. Upload the file with POST /api/pinning and get its CID back. Or, if the content already exists on IPFS, pin it by CID with POST /api/pinning/pinByHash, and we fetch the blocks from the network. This is the pin-by-CID example from the AIOZ Pin API reference (not run here):

async function pinByCid(cid: string, name?: string) {
  const res = await fetch(`${BASE}/pinning/pinByHash`, {
    method: 'POST',
    headers: { ...PIN_HEADERS, 'Content-Type': 'application/json' },
    body: JSON.stringify({ hash_to_pin: cid, metadata: name ? { name } : undefined })
  })
  return res.json()
}

Once pinned, the CID loads over HTTPS at https://public.aiozpin.network/ipfs/<CID>. The public gateway is meant for testing and allows 15 requests per minute per CID. A premium gateway has no set rate limit for production traffic. Pinned content also benefits from AIOZ DePIN's smart caching, which replicates frequently accessed content. How AIOZ Pin works shows the full picture.

Next step: follow the AIOZ Pin quick start to pin your first CID.

Frequently Asked Questions

What is content addressing? Naming data by a cryptographic hash of its content instead of by its storage location. In IPFS, the name is a CID, and any change to the content produces a different CID.

What is the difference between content addressing and location addressing? Location addressing (an HTTP URL) names a server and path, and the content behind it can change. Content addressing (an IPFS CID) comes from the content's hash, so it changes when the content does and works from any host that has it.

Is a CID the same as a file hash? No. A CID includes the hash of the root block plus codec and hash-function information. The file is also split into blocks first, so a CID won't match the file's SHA-256 checksum.

Does content addressing prevent link rot? It prevents link rot caused by one server going away, because any host can serve the CID. It doesn't help when nobody hosts the content at all.

Is content addressing more secure? For tamper detection, yes: your node can check every block against its hash locally. It doesn't make data more available, which depends on hosting.

Does AIOZ Pin change how CIDs work? No. CIDs are computed the same way with or without AIOZ Pin. What AIOZ Pin adds is a pin that keeps the blocks stored and the CID resolvable.

Can you edit a file on IPFS? Not in place. Changing the content produces a new CID and a new DAG, while the original content keeps its original CID. Use IPNS or DNSLink when you need one address that follows the latest version.

Does re-uploading an edited file replace the old pin on AIOZ Pin? No. The edited file gets its own CID and its own pin. The original stays pinned, and billed for storage, until you unpin it.

Related Reading

• How Does IPFS Work? Merkle DAGs, Chunking, and Routing - how a CID gets derived, step by step
• Anatomy of a CID - the multihash, multicodec, and multibase parts
• How IPFS Finds and Retrieves Your Files - how the network answers "who has this CID"
• What Is IPNS? How IPFS Names Point to Changing Content - the mutable pointer that gives immutable content a stable address
• Content Moderation on IPFS - what content addressing means for takedowns
• What Is IPFS? - the concept-level introduction
• Pin by CID on IPFS Without Re-Uploading Your Files - keep content you did not upload by pinning its CID

References

• IPFS Docs: Content Identifiers (CIDs)
• IPFS Docs: Immutability
• IPFS Docs: The lifecycle of data in IPFS
• AIOZ Pin Pinning API documentation
• AIOZ Pin Limit documentation