What is IPFS, in plain English?
Zero-jargon explanation of IPFS for NFT founders, web devs, and curious users. CIDs, pinning, gateways, and what the protocol actually guarantees.
IPFS comes up everywhere in the NFT, Web3, and decentralized-storage conversation, and most explanations start with words like "distributed hash table" and "DAG" and lose people in the first paragraph. This post does the opposite: zero jargon, one mental model, ten minutes to understand what IPFS actually is and what it is not.
The mental model: addressing by content, not by location
When you load a normal website, your browser asks for a URL like https://example.com/cat.png. That URL is a location — it says "go to the server named example.com and ask for the file at the path /cat.png." If example.com goes offline or moves the file, the URL breaks. The URL doesn't describe the picture itself; it describes where to find the picture.
IPFS flips this. Instead of giving you a location, it gives you a content address: a long hash like bafybeihrplkqxfivnfoj2tcvkd4mxrujef6lhu3h53o6nzwmp2upst26c4 (called a CID, short for "content identifier"). That hash is a mathematical fingerprint of the file's exact bytes. Change a single pixel of the image and you get a completely different CID. Keep the bytes identical and the CID is identical, forever, no matter who's holding the file.
The two consequences of content-addressing
Once you grok this one idea — "the address is the content's fingerprint, not its mailbox" — everything else about IPFS follows.
Consequence one: any provider can serve you the file. If you have the CID, you can ask any IPFS node in the world "do you have this content?" If they have the bytes that match this fingerprint, they can serve them and you can verify them. There's no single server you depend on. Provider A goes down, you ask provider B, you get the same file. The CID is your portable proof of what you want.
Consequence two: content cannot lie. If a server hands you bytes that hash to a different CID than the one you asked for, you know they've tampered with the content. The verification is mathematical, not based on trust. This is why NFT metadata stored as an ipfs://<cid> URI is tamper-proof in a way that https://example.com/metadata.json is not — the marketplace fetching the metadata can verify the hash matches what the smart contract recorded.
So what's an "IPFS pinning service"?
Here's the part that confuses everyone: IPFS itself doesn't guarantee anyone has your file. It's a protocol, not a server. You could upload your image to IPFS from your laptop, but the moment you close your laptop, no one else on the network is holding those bytes anymore. The CID still exists conceptually, but if no node has the content, no one can fetch it.
A pinning service is a company that runs IPFS nodes 24/7 and promises to keep your content there. You pay them (or use a free tier) and they hold your bytes. Pinata, NFT.Storage, Storacha (formerly web3.storage), and Octopin are pinning services. They're the "hosting" layer for an otherwise stateless protocol.
This distinction matters a lot, because most NFT projects think "uploading to IPFS" is the same as "keeping the file online forever." It is not. The protocol is permanent. Your access depends on whoever you're paying to host the bytes. We have a separate post that unpacks this misconception — recommended reading before you launch anything that depends on long-term IPFS availability.
Where IPFS shines, and where it doesn't
IPFS is excellent for content that's meant to be public, immutable, and addressable from anywhere — NFT media, Wikipedia archives, dataset snapshots, software release artifacts, podcast episodes. The content-addressing means you can verify integrity, cache aggressively, and migrate hosts without breaking links.
It's a poor fit for content that needs to change in place (every edit produces a new CID, breaking any URL that referenced the old one), content that needs access control (anyone with the CID can fetch the bytes from any provider), or low-latency private databases (it's a protocol for shipping content, not a query engine).
What you should remember
- A CID is a fingerprint of the file's contents. Same bytes everywhere produce the same CID, always.
- You can fetch a CID through any IPFS gateway. There's no single point of failure for the URL itself — only for the hosting.
- IPFS "hosting" is called pinning. A pinning provider is who actually keeps your content alive on the network.
- If your pinning provider shuts down and no one else has your content, your CID still exists on paper but the content is gone.
That last point is the single most important thing to understand about IPFS in 2026. The pinning landscape changed dramatically this year when Storacha announced its shutdown — projects that thought their NFTs were "on IPFS forever" suddenly had a deadline. We wrote a migration playbook for that case, and we built Octopin partly because we kept seeing collections learn this lesson the hard way.
Try Octopin for free
1 GB free. Unlimited bandwidth. No credit card.