
Content moderation on IPFS works per copy, not per address. A pinning service can unpin its copy and a gateway can refuse to serve a CID, but any other peer holding the file keeps it reachable. You can block access through your own infrastructure; you can't erase a CID network-wide.
TL;DR:
ipfs.io, dweb.link), not to the IPFS network as a whole or to every gateway operator independentlyA takedown notice against a normal web server works because the server is the address: remove the file from that one machine, and the URL stops resolving, full stop. This series' content-addressing article covers exactly why IPFS breaks that assumption: a CID is not a location, it's a description of content, and the same CID keeps working through any peer that independently has it. Removing one host's copy doesn't touch the address itself, only that one host's participation in serving it.
A pinning service, or any individual node operator, has real, concrete power over its own infrastructure: it can unpin a file, covered in this series' garbage collection article, and stop hosting it. It can also refuse to serve a request through its own gateway. Both of those are effective actions within that operator's own scope. Neither one reaches beyond it: unpinning removes one node's commitment to keep the content available, but has no effect on any other peer, anywhere, that independently pinned the same CID before or after.
This isn't a hypothetical gap papered over with vague claims about decentralization, there's a specific, documented tool built to address it at the layer where it can be addressed: the Bad Bits Denylist, maintained by Protocol Labs, a shared list of hashed CIDs flagged for reasons like copyright violation or malware. Gateway operators and pinning services can voluntarily check requests against this list and refuse to serve anything on it. It's explicitly opt-in and gateway-level: adopting the denylist blocks access through participating gateways, and does not remove the underlying content from the IPFS network, the same structural limit covered above, just formalized into a real, usable tool rather than left as an abstract problem.
The gap between "block at the gateway" and "remove from the network" has caused documented, concrete friction. Gateway operators have reported receiving DMCA takedown notices covering thousands of URLs where the vast majority were never requested through that gateway's own traffic logs, meaning the notice sender had no real way to confirm the gateway was serving the content at all before demanding it stop. This is a direct consequence of content addressing's own design: a CID being valid and resolvable in principle says nothing about whether any specific gateway operator has ever served it, which makes a blanket, unverified takedown request structurally different, and structurally harder to act on precisely, than one aimed at a single web server hosting a known file.
It's worth being precise about scope here too: the IPFS Foundation and Protocol Labs' own Code of Conduct, and the Bad Bits process behind it, applies specifically to the public gateways they operate directly, ipfs.io and dweb.link. It does not automatically bind every gateway operator or pinning service on the network, each of those makes its own independent decision about whether to adopt a denylist, run their own moderation process, or do neither. There is no single governing body with the power to enforce a takedown across every participant in the network at once, which is a direct structural consequence of the same decentralized design this entire series has been describing.
The lever AIOZ Pin, or any customer using it, has is the same one covered throughout this series: unpinning content removes AIOZ Pin's own hosting commitment to it. That's a real, effective action within AIOZ Pin's own infrastructure, consistent with how any pinning service's moderation capability works, not a special exception. What it does not do, and what no pinning service anywhere can honestly claim to do, is remove content from the broader IPFS network if other peers independently hold it. Anyone evaluating a pinning service's moderation posture is asking about that service's own policies for what it will and won't host, not about a network-wide removal capability that doesn't exist for any provider.
Can a pinning service remove content from IPFS entirely? No. It can unpin content and stop hosting its own copy, and it can refuse to serve requests through its own gateway. Neither action removes the content from other peers that independently hold it.
What is the Bad Bits Denylist? A shared list of hashed CIDs maintained by Protocol Labs, flagged for reasons like copyright violation or malware, that gateway operators can voluntarily check requests against and refuse to serve. It's opt-in and gateway-level.
Does unpinning content on AIOZ Pin remove it from the whole network? No. It removes AIOZ Pin's own hosting commitment for that content. If any other peer has independently pinned the same CID, it remains available through them.
Why have gateway operators received DMCA notices for content they never served? Because a CID being technically valid doesn't mean a specific gateway has ever served it. Some takedown processes have targeted URLs without verifying they appeared in that gateway's own traffic logs first.
Does the IPFS Foundation's Code of Conduct apply to every IPFS gateway? No. It applies specifically to the public gateways Protocol Labs and the IPFS Foundation operate directly. Other gateway and pinning service operators set their own independent policies.
Is there a way to remove content from IPFS network-wide? Not through any single action. Content addressing means the same CID resolves through any peer that has it, and no central authority can unilaterally revoke that across every independent node on the network.

An IPFS dedicated gateway on AIOZ Pin is called a premium gateway. See what the free plan limits, what a paid plan adds, and what happens at zero balance.

Pin by CID asks a pinning service to fetch content already on IPFS and keep it. Covers the AIOZ Pin pinByHash call, statuses, and why a pin stalls on Pinning.

IPFS gateway not working? Read the status code first, then check the CID, your request rate, and whether anyone is providing the content. Here is the order.

ERC-1155 metadata on IPFS breaks when filenames ignore the {id} rule. Here is the exact 64-character format, a working folder layout, and the per-token option.

AIOZ Pin rate limits in one place: 180 requests per minute for the API, 15 per CID on the public gateway, and no predefined limit on premium gateways.

IPFS pin stuck on Pinning? Here is what Pinning, Pinned, and Failed mean on AIOZ Pin, why big directories can sit there, and how to read a pin's real state.