
Most web pages don't survive long. IPFS solves the storage and addressing half of that problem, distributing files across a peer-to-peer network instead of one server, but it doesn't solve persistence on its own. Nodes periodically run garbage collection to free up space, and content nobody's actively keeping around can quietly get dropped. Pinning is the mechanism that prevents that, and a pinning service is what makes pinning practical without running your own IPFS infrastructure. Here's exactly how it works.
TL;DR:
IPFS nodes have limited storage capacity, and to manage that, they periodically run garbage collection, a process that clears out data to free up space. Content that nobody has explicitly told the node to keep is fair game to be removed during that process, including data other people might still be trying to reach. That's the specific gap pinning closes: pinning marks data to be retained through garbage collection instead of cleared, which is what actually makes "stored on IPFS" mean "stays reachable on IPFS."
A pinning service is a third-party provider that manages the pinning process for you. Rather than running your own IPFS node, keeping it online, and monitoring its storage, you upload content to the service and it handles pinning that content across infrastructure it maintains. In practice, that removes several real burdens:
One detail worth knowing before picking a provider: the IPFS Pinning Service API is a standardized specification, not something each vendor invents independently. Multiple providers implement the same spec, which means a pinning integration built against the standard API can, in principle, switch providers without a full rewrite. That portability is a genuine, underused advantage of sticking to standards-based tooling rather than a provider's proprietary API.
AIOZ Pin is a pinning service built on the AIOZ DePIN, a distributed network of independent nodes rather than one centralized provider's infrastructure. Concretely, that means:
pinFilesToIPFS(), pinFolderToIPFS(), pinByHash(), plus a standalone CLI tool) for pinning programmatically rather than through a dashboard aloneNot every claim of "reliable pinning" means the same thing in practice. A few questions worth asking before committing to a provider:
None of these are exotic requirements, but they're also not always obvious from a provider's marketing page, and they're exactly the kind of thing worth checking against actual documentation rather than assuming.
Why does IPFS content ever disappear if it's decentralized? Because a node's storage is finite. Garbage collection periodically clears content nobody has explicitly pinned, and if no other node is hosting a copy, that content becomes unreachable.
What does "pinning" actually do? It marks specific data to be retained through a node's garbage collection process, guaranteeing that node keeps a copy instead of clearing it to free up space.
Do I need to run my own IPFS node to use a pinning service? No. That's the specific problem a pinning service solves, it manages the pinning and hosting infrastructure so you don't have to run or maintain a node yourself.
What is the IPFS Pinning Service API? A standardized specification for pinning-service integrations. Because multiple providers implement the same API, switching providers doesn't necessarily require rewriting your integration from scratch.
How is AIOZ Pin's billing different from a typical cloud storage subscription? It's pay-as-you-go, funded by depositing AIOZ tokens into an account wallet, rather than a fixed monthly tier. Usage is deducted from that balance daily as storage and bandwidth actually accrue.
Can pinned content still be lost? The garbage-collection risk pinning solves is real, but no storage guarantee is absolute. Reviewing a provider's actual replication and persistence mechanics, not just the marketing claim, is worth doing before treating any single copy as permanent.

Pinning services can remove their own copy of a file. They cannot remove it from IPFS. Here is exactly what a takedown does and does not accomplish.

libp2p connections can run over more than one transport. Here is exactly what changes with QUIC instead of TCP, and why IPFS dials both at once.

The DHT answers who has a CID. GossipSub answers a different question: how do peers push real-time updates to everyone listening, without a lookup at all.

js-ipfs is deprecated. Helia is what replaced it: a modular, TypeScript-first IPFS implementation built for the browser and Node.js. Here is how it fits.

Not every retrieval needs the whole DAG. IPLD Selectors describe exactly which nodes to traverse and match, so a client can fetch a slice, not everything.

Almost no browser understands ipfs:// links natively. Here is exactly why, what IPFS Companion actually does about it, and why gateway URLs took over instead.