When I first started reading about IPFS, I kept seeing the letters “CID” without any explanation. Content Identifier. Okay. Identifies content. I assumed it was just another word for a URL — the address you use to find a file. That assumption turned out to be wrong in a way that actually matters.

A normal URL tells you where something is. IPFS CID tells you what something is. That’s a completely different thing, and the difference explains why CIDs are used for NFT storage in the first place.

What a CID Actually Is

When you upload a file to IPFS, the system runs a mathematical process on the file’s contents — a hash function — and produces a unique string of characters. That string is the CID. It’s derived entirely from the file itself, not from where it’s stored or who uploaded it.

Two identical files will always produce the same CID. If you change even one character in the file, the CID changes completely. This makes the CID a kind of fingerprint — specific to that exact version of that exact file, permanently.

The practical result: if you know a file’s CID, you can verify that any copy of the file you receive is authentic. If the CID matches, the file is unchanged. If it doesn’t, something is different — whether intentionally or by accident.

Why This Matters for NFTs

Here’s the problem with regular URLs for NFT metadata: they point to a location, not a file. If the file at that location changes — or disappears — the URL still exists, but what it points to is different or gone. The NFT on the blockchain stays the same, but the image it was supposed to represent is now something else, or nothing.

When an NFT stores a CID instead of a URL, it stores a description of the file, not just an address. If you retrieve the file using that CID and the contents match, you know you have the original. If someone tries to swap the file, the CID won’t match anymore — you’d know immediately something changed.

This is why you’ll hear people say “store metadata on IPFS” as a sign of a more trustworthy NFT project. What they really mean is: the NFT is pointing to a CID, not a centralised server URL that could be changed or deleted without anyone noticing.

The Analogy That Helped Me

Think about the difference between giving someone your home address versus a description of your house. The address tells them where to go — but if you move, the address becomes useless, and someone else’s house might be at that address later. The description — size, layout, distinguishing features — describes something specific. If you show up somewhere and the description doesn’t match, you know it’s the wrong place.

A CID is the description. It’s tied to the content, not the location. On IPFS, the file can be stored on many different nodes in many different places — but the CID stays the same, because the CID is about what the file is, not where it lives.

What It Looks Like in Practice

A typical IPFS CID looks something like this: QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco — a long string starting with “Qm” for older CID formats, or “bafy” for newer ones. When you see this in an NFT’s metadata, it means the image or data was stored using content addressing — the hash-based system — rather than a plain server URL.

You can check this yourself on most NFTs by looking at the token’s metadata on PolygonScan or a similar explorer. If the image URL starts with ipfs:// followed by a long string, the project is using content addressing. If it starts with https:// pointing to a server domain, it’s using a regular URL — and you have no guarantee the file won’t change.

What CIDs Don’t Guarantee

A CID tells you the file is unchanged — it doesn’t tell you the file will always be available. IPFS is a distributed network, and files are only available as long as at least one node is actively storing and serving them. If no one is “pinning” a file — keeping a persistent copy — it can disappear from the network even if the CID is valid.

This is why services like Pinata or Arweave exist alongside IPFS. Pinata pays to keep files pinned on IPFS. Arweave takes a different approach — you pay once for permanent storage, and the network is designed to keep data available indefinitely. CIDs verify integrity; pinning or permanent storage services handle availability.

Neither solves everything. But together, they’re meaningfully better than an NFT pointing to a JPEG on someone’s server that could be taken down tomorrow.

Where I’m Still Learning

I understand the basic concept of CIDs well enough now, I think. What I’m less clear on is the difference between CIDv0 and CIDv1 — the older “Qm” format versus the newer “bafy” format — and what practical difference that makes for most NFT use cases. If you’re building something and this distinction matters to you, I’d look it up directly rather than relying on my current understanding. I’m still working through it.