The short answer in the IPFS vs centralized NFT hosting debate: IPFS gives buyers a cryptographic guarantee the image cannot be swapped or quietly deleted, while a centralized server (AWS, your own VPS, a CDN) is faster and cheaper to run but only stays alive as long as you keep paying and choose not to change it. The token on-chain is just a pointer. What that pointer references decides whether the art outlives you.
That is the whole problem in one sentence. An NFT is a line in a smart contract that says "this token's metadata lives at this URL." If that URL is a normal web address you control, the holder is trusting you. If it is an IPFS content address, they are trusting math. Most guides that rank for this topic are written by pinning companies that want you on IPFS no matter what, so this one weighs both sides honestly, including the cases where a centralized server is genuinely the right call.
What "Hosting" Actually Means for an NFT#
People assume the picture lives "on the blockchain." It almost never does. Storing a full-resolution image on Ethereum mainnet would cost a fortune in gas, so the chain stores a tiny tokenURI that points somewhere else. That somewhere else is what we are comparing.
There are usually two layers, and confusing them is the most common beginner mistake:
- The metadata JSON holds the name, description, traits, and an
imagefield. This is what marketplaces read. - The media file (the PNG, GIF, MP4, or SVG) is referenced by the
imagefield inside that JSON.
Both layers need a home. You can put the JSON on IPFS and the image on a server, or vice versa, but a chain is only as strong as its weakest link. If your metadata is immutable but it points at an image on a server you forget to renew, the art still disappears. Build the file with a free NFT metadata generator so the image and animation_url fields are formatted correctly before you decide where to pin them.
Key point: immutability is a property of the whole pointer chain, not one file. A "permanent" NFT with one centralized link in the chain is not permanent.
IPFS vs Centralized NFT Hosting: The Core Tradeoff#
IPFS (the InterPlanetary File System) uses content addressing. Instead of naming a file by where it lives, it names the file by a hash of its contents, called a CID (content identifier). Change one pixel and the CID changes completely. That is the entire magic trick: a CID is a fingerprint, so the address itself proves the file has not been altered.
Centralized hosting uses location addressing. https://mysite.com/nft/1.png says nothing about the contents. You can replace that file with anything, anytime, and the URL stays the same. The buyer has no way to know if today's image matches the one they bought.
| Factor | IPFS (with pinning) | Centralized server |
|---|---|---|
| Tamper-proof | Yes, CID changes if file changes | No, file can be swapped silently |
| Survives if creator vanishes | Yes, if pinned by others | No, dies when hosting lapses |
| Speed (first load) | Slower without a fast gateway | Fast, especially on a CDN |
| Monthly cost | Low to moderate (pinning fees) | Low, but ongoing forever |
| Setup difficulty | Moderate (CIDs, pinning) | Easy (upload a file) |
| Single point of failure | No | Yes (your account, your bill) |
| Best for | Collections meant to last | Utility, dynamic, or short-lived assets |
The headline tradeoff is trust versus convenience. IPFS removes the need to trust the creator but adds friction. A server removes friction but reinstalls the trust requirement the whole point of an NFT was supposed to eliminate.
The rug-pull angle nobody markets#
Here is the scenario that makes this concrete. A project mints 10,000 NFTs with metadata hosted at api.theproject.io. Floor price climbs. Six months later the team lets the domain expire, or worse, points it at a placeholder. Every NFT in that collection now shows a broken image. The token still exists on-chain, but the art is gone, and there is nothing holders can do.
This is not hypothetical. Centralized-hosted collections have gone dark exactly this way, sometimes by accident and sometimes deliberately. With IPFS, even if the original team disappears, anyone can re-pin the content from the CID and the images come back identical. That resilience is the single strongest argument for IPFS, and it is the one pinning vendors undersell because "your art survives a rug" is a grim sales pitch.
When Centralized Hosting Is Actually the Right Choice#
The honest part most IPFS evangelists skip: centralized hosting is not always wrong. Several legitimate use cases favor it.
- Dynamic NFTs. If your token is meant to change (a game character that levels up, a membership that updates tiers), you need mutable metadata. IPFS immutability works against you here. A server, or an on-chain renderer, fits better.
- Utility tokens and tickets. A concert ticket NFT that expires in a week does not need 100-year permanence. Speed and cost matter more.
- Rapid iteration before launch. During testing you will reupload art dozens of times. Re-pinning to IPFS every time is slower than overwriting a file on a server.
- High-traffic reveals. A fast CDN can outperform a congested public IPFS gateway during a hyped mint when thousands hit the metadata at once.
The mature pattern many projects use: develop on a centralized server, then freeze the final art to IPFS (or Arweave) right before or right after mint, and update the contract's base URI to the immutable location. You get iteration speed early and permanence where it counts.
Warning: if you promise holders "stored on IPFS forever" in your marketing, then quietly leave the metadata on a server, that is a credibility problem and increasingly something buyers check. Match your storage to your promises.
IPFS Is Not Automatically Permanent (The Pinning Catch)#
The biggest misconception about IPFS is that uploading a file makes it permanent. It does not. IPFS is a network of nodes that share content, but a file only stays available while at least one node keeps a copy "pinned." If every node that has your file goes offline and nobody else pinned it, the CID still exists but resolves to nothing. This is called garbage collection.
That is why pinning services exist. Pinata, nft.storage, web3.storage, and Filebase all run nodes that promise to keep your content pinned, usually for a fee or a free tier with limits. The CID guarantees the file cannot change. The pinning service guarantees it stays online. You need both.
So "store it on IPFS" in practice means "pin it on at least one reliable service, ideally more than one." Treat pinning like backups: one copy is a single point of failure wearing a decentralized costume.
Arweave vs IPFS for NFTs#
Arweave takes a different bet. Instead of ongoing pinning fees, you pay once and the network is economically incentivized to store the data for roughly 200 years. For NFTs specifically, this is appealing because there is no recurring bill to forget.
- IPFS: content-addressed, flexible, but permanence depends on continuous pinning (an ongoing cost or risk).
- Arweave: pay-once permanent storage, no recurring fee, but less flexible and a smaller ecosystem of tooling.
Many creators use Arweave for the immutable media file and IPFS for metadata they might still be tweaking pre-launch, or just pick Arweave end to end for set-and-forget permanence. Neither is "better" universally. Arweave optimizes for never thinking about it again. IPFS optimizes for flexibility and a larger tooling ecosystem.
Gateway URLs vs Native ipfs:// Links#
A subtle decision that trips up new minters: how you write the IPFS link in your metadata.
You have two formats:
- Native protocol:
ipfs://bafy.../1.png - Gateway URL:
https://ipfs.io/ipfs/bafy.../1.pngorhttps://gateway.pinata.cloud/ipfs/bafy.../1.png
Use the native ipfs:// form in your stored metadata whenever possible. Gateway URLs hard-code a dependency on one specific gateway, and if that gateway goes down or rate-limits you, the link breaks even though the content is perfectly fine on IPFS. The ipfs:// form lets every wallet and marketplace resolve the CID through whatever gateway it prefers. OpenSea, Magic Eden, and major wallets all understand ipfs:// natively.
A clean metadata file uses ipfs:// for both the metadata location and the image field inside it. When you build your JSON with the NFT metadata generator, keep the IPFS-ready URL hints in native form and only swap in a gateway URL for quick browser previews during testing.
A Practical Decision Framework#
Strip away the ideology and the choice comes down to a few questions about your specific collection.
- Is the art meant to last decades? Yes points strongly to IPFS or Arweave. No (tickets, short-term utility) makes a server defensible.
- Will the metadata ever need to change? Yes means you need mutability, which IPFS immutability fights. No favors IPFS.
- Can you commit to ongoing pinning or a pay-once model? If you cannot guarantee a pinning bill gets paid for years, Arweave's pay-once model removes that failure mode.
- What did you promise buyers? If your pitch says "permanent and decentralized," your storage has to back that up or you have misled holders.
For most art-focused PFP and 1-of-1 collections that hold value over time, the answer is decentralized storage with native ipfs:// links and at least two pinning services, or Arweave for true set-and-forget. For dynamic, utility, or disposable tokens, a well-run server is reasonable, provided you are honest about it.
Whatever you choose, validate the wallet addresses in your allowlist and royalty config first with a crypto wallet address validator, and if your launch involves a token alongside the NFT, generate the contract safely with the ERC-20 token contract generator. Get the metadata structure right at the source and the hosting decision becomes a clean swap of one base URI.
Conclusion: Match Storage to Stakes#
The IPFS vs centralized NFT hosting decision is not about which technology is morally superior. It is about matching permanence to what you are actually selling. IPFS and Arweave buy you a guarantee that survives your domain renewal, your hosting bill, and even your disappearance, at the cost of more setup and ongoing pinning discipline. A centralized server buys you speed, low friction, and mutability, at the cost of asking buyers to trust you indefinitely.
If you are minting art meant to outlive you, use content addressing, pin it in more than one place, and write native ipfs:// links. If you are shipping a short-lived utility token, a fast server is fine, just say so. Either way, build the metadata correctly before you pin anything, because the strongest immutability guarantee in the world is useless if it points at the wrong file.
Frequently Asked Questions#
Should NFT images be stored on IPFS? For collectible art and anything meant to hold value long term, yes, IPFS (or Arweave) is the safer choice because the content address proves the file was never swapped and the art survives even if you stop running servers. For dynamic or short-lived utility NFTs that need to change, a centralized server can be the better fit. Match the storage to whether the asset must be permanent and immutable.
Is IPFS truly permanent for NFTs? Not on its own. IPFS guarantees the file cannot be altered (the CID would change), but it does not guarantee the file stays online. Content stays available only while at least one node keeps it pinned, which is why you use a pinning service like Pinata, ideally more than one. Without active pinning, the CID can resolve to nothing.
What is the difference between a CID and a gateway URL?
A CID (content identifier) is the cryptographic fingerprint of your file and is what makes IPFS tamper-proof. A gateway URL like https://ipfs.io/ipfs/<cid> is just one website's way of serving that CID over HTTPS. Store the native ipfs://<cid> form in your metadata so you do not depend on a single gateway staying online.
Is Arweave better than IPFS for NFT storage? They optimize for different things. Arweave is pay-once and economically designed to persist for roughly 200 years with no recurring bill, which suits set-and-forget permanence. IPFS is more flexible with a larger tooling ecosystem but needs continuous pinning. Many projects use Arweave for the final media file and IPFS for metadata during development.
Can a project change my NFT's image after I buy it? If the metadata or image sits on a centralized server, yes, the team can swap or delete the file at any time and the token URL stays the same. If it uses native IPFS or Arweave content addressing, no, any change produces a different CID, so the original art is locked. This is the core reason buyers increasingly check where a collection's assets are hosted before purchasing.
Do I need IPFS for the metadata JSON, the image, or both?
Ideally both, because a pointer chain is only as strong as its weakest link. If your metadata is immutable on IPFS but its image field points at a server that later goes offline, holders still see a broken image. Pin the JSON and the media to decentralized storage and reference them with native ipfs:// links throughout.
