Content Addressing

How IPFS identifies files by what they contain, not where they're stored.

Location vs. content

Traditional web URLs point to a location — a specific server at a specific address. If the server goes down or the file moves, the link breaks. This is location-based addressing.

IPFS works differently. Every file is identified by a cryptographic hash of its contents — a content identifier (CID). The CID doesn't say where the file is; it says what the file is. Any node on the network that has the file can serve it, and anyone who receives it can verify it's the right file by recalculating the hash.

TIP

Think of it like a fingerprint: two identical files always produce the same CID, and even a single-byte change produces a completely different CID.

Why it matters

1. Integrity — You can always verify that the file you received matches the CID you requested. Tampering is impossible without changing the CID.
2. Deduplication — If two users upload the same file, it produces the same CID. The network only stores one copy.
3. Permanence — Files aren't tied to a server. As long as at least one node pins the CID, the file is available from anywhere on the network.
4. Decentralization — No single point of failure. Content can be served by any node that has it.

How IPFS.NINJA uses content addressing

When you upload a file through our API, the IPFS cluster computes the CID and pins the file. The CID is returned in the response and can be used to access the file through any IPFS gateway — ours at ipfs.ninja/ipfs/<CID> or any public gateway like dweb.link.