Why NFT Projects Need a Pinning Service, Not Just IPFS

Minting an NFT on IPFS doesn't automatically keep its image or metadata online. That's a common misunderstanding: putting a file on IPFS gives it a content-addressed CID, but nothing about IPFS itself guarantees any node keeps storing it. Without an active pin somewhere, IPFS nodes are free to garbage-collect content nobody's actively requesting, which is exactly the scenario that leaves an NFT's tokenURI pointing at a CID nothing serves anymore. This is why NFT projects need a pinning service specifically, not just an IPFS upload, and it's what AIOZ Pin's NFT Management component is built around.

TL;DR:

• An NFT's on-chain record only stores a pointer (a CID), not the actual image or metadata
• Without an active pin, that CID can become unreachable through normal IPFS garbage collection
• AIOZ Pin's pinNft() method pins an NFT's asset and metadata together in one call, closing the gap where one gets pinned and the other doesn't

What Actually Breaks Without Pinning

An NFT smart contract typically stores a tokenURI, a pointer like ipfs://<CID>, not the image or JSON metadata itself. That data lives off-chain, and IPFS nodes only keep serving content that's actively pinned somewhere in the network. If you upload an NFT's asset and metadata to a node that never gets a real, ongoing pin, whether it was a free trial that expired, a personal node that went offline, or an upload that was never explicitly pinned in the first place, garbage collection can reclaim that space, and the CID your contract points to stops resolving. The token still exists on-chain, but the image and metadata behind it are gone.

Two Ways NFT Metadata Fails Independently

The asset (the image, video, or audio file) and the metadata (the JSON describing name, description, and attributes) are usually pinned as separate objects, sometimes through separate uploads. That creates a specific failure mode: it's possible for one to stay pinned while the other doesn't, leaving you with an image nothing describes, or metadata pointing at an asset CID that no longer resolves. This isn't a hypothetical, it's a direct consequence of treating a two-part object (asset plus metadata) as two independent pin operations instead of one atomic one.

Content Addressing as a Side Benefit: Tamper Detection

Because a CID is derived from the content itself, not assigned separately, any attempt to modify pinned NFT metadata after the fact produces a different CID, instantly visible rather than silent. For an NFT specifically, where the whole point is that the metadata a buyer saw at mint time is the metadata that stays attached to the token, this matters more than it does for typical file storage. A URL can be silently repointed at different content; a CID can't be without the change being obvious.

How AIOZ Pin's NFT Tooling Addresses This Directly

NFT Management is one of AIOZ Pin's three named product components, not an afterthought bolted onto general file storage. Concretely, that means pinNft() in the Node.js SDK, which pins an NFT's asset and its metadata together in a single call, removing the two-separate-pins failure mode described above. Content served through AIOZ Pin's Premium Gateways isn't subject to the rate limits public IPFS gateways enforce, relevant if your NFT's metadata gets hit with real traffic during a mint or a marketplace listing spike. And because AIOZ Pin implements the same IPFS Pinning Service API standard other pinning providers use, none of this locks you into AIOZ-specific tooling if you later need to move.

Why a Broken Pin Doesn't Always Show Up Immediately

One detail worth knowing before assuming a project is safe just because nothing looks broken today: marketplaces and wallet apps commonly cache an NFT's image and metadata after the first time they load it, rather than re-fetching from IPFS on every view. That means a pin quietly failing doesn't necessarily produce an immediate broken image everywhere it's displayed, cached copies keep showing the last-known-good version for a while. The failure surfaces later and unevenly: a new marketplace indexing the collection for the first time gets a broken result immediately, while an existing listing with a cached thumbnail looks fine until that cache expires or gets cleared. This is part of why "it looks fine right now" is a weak signal that pinning is actually healthy, the visible symptom covered in detail elsewhere on this blog can lag the actual underlying failure by a meaningful amount of time, which makes verifying the pin's real status directly, not just glancing at how a listing currently renders, the more reliable check.

This Applies Beyond a Single Image and JSON File

Everything above is described in terms of one asset and one metadata file, the common case for a single NFT, but the same reasoning scales to whatever a project is actually minting: a generative collection with thousands of individual assets, an on-chain game referencing hundreds of item sprites, a music NFT bundling audio alongside artwork and metadata. The failure mode doesn't change with scale, more files pinned without an ongoing hosting commitment is just more surface area for the same underlying problem, a CID that's valid but unreachable because nothing is actively keeping it available. Whatever the actual asset mix, the fix is identical: an active, ongoing pin behind every CID a contract references, not a one-time upload assumed to persist on its own.

Frequently Asked Questions

Does minting an NFT on IPFS keep its metadata online automatically? No. An NFT's on-chain record stores a CID pointer, not the actual file. Without an active pin, IPFS nodes can garbage-collect content nobody's requesting, leaving the CID unreachable.

Why do NFT projects need a pinning service instead of just uploading to IPFS? A basic IPFS upload without an ongoing pin can be reclaimed through normal garbage collection. A pinning service actively keeps that content available on an ongoing basis.

Can an NFT's image stay online while its metadata disappears, or the reverse? Yes, if the two are pinned as separate operations, one can remain pinned while the other doesn't, since they're independent pin operations by default.

How does AIOZ Pin's pinNft() method help with this? It pins an NFT's asset and its metadata together in a single call, so both persist or fail together instead of independently.

Does content addressing help detect tampering with NFT metadata? Yes. A CID is derived from the content itself, so any modification produces a different CID, making tampering visible rather than silent, unlike a standard URL that can be silently repointed.

Related Reading

• How AIOZ Pin Works: Pinning, Gateways, and NFT Tools - the full mechanics of AIOZ Pin's NFT Management component
• Getting Started with the AIOZ Pin Node.js SDK: A Guide - the exact pinNft() code needed to pin an asset and metadata together
• Best NFT.storage Alternatives in 2026 (Featuring AIOZ Pin) - what happened to projects that relied on a pinning service that shut down
• The NFT Metadata Problem: When Your IPFS Pin Expires - what this failure actually looks like from a collector's side, months after it happens

References

• AIOZ Pin Infrastructure Documentation
• AIOZ Pin SDK Package (npm registry)