Where your NFT's image actually lives

The chain stores a pointer, never a picture. Following that pointer to the end explains why collections go blank years after mint — and how to tell in advance whether yours will.

1 September 20264 min readupdated 5 September 2026

A dark token bearing a chain symbol connects by a red line to a separate frame containing a red landscape.

Almost no NFT contains its own picture. The chain holds a token id, an owner, and a string pointing somewhere else. The picture lives at the end of that string, on infrastructure somebody has to keep running.

This is not a scandal — storing megabytes on a blockchain would cost more than the art is worth — but it is the fact that decides whether a collection still looks like anything in ten years.

The three places it can be

A web server

The pointer is an ordinary https:// URL. The picture lives wherever the project put it, and it is available exactly as long as someone pays that bill and renews that domain.

Every failure mode here is mundane: a lapsed domain, a closed company, an expired card, a migration that broke the paths. None of them involves anything crypto. This is how most of the collections that have gone blank went blank.

IPFS

The pointer is ipfs:// followed by a content identifier — a hash of the bytes themselves. This is a genuine improvement and it is worth being precise about what it improves.

Because the address is derived from the content, nobody can substitute a different picture at the same address. Integrity is solved. But IPFS is a way of addressing data, not a promise to store it. Bytes stay available only while at least one node keeps them pinned. Pinning is a service, and it is usually a subscription.

So the failure mode moves rather than disappearing: instead of the picture being swapped, it becomes unreachable while the hash still correctly describes it. Content-addressed, and gone.

Permanent storage

Arweave and comparable systems invert the billing model. You pay once, and the payment endows storage for a very long horizon rather than renting it monthly. There is no subscription to forget and no card to expire.

The trade is that you are trusting an economic model — that the endowment keeps paying for storage as costs fall — rather than a company's willingness to keep paying a bill. That is a different risk, and for most collections a considerably better one.

The gateway problem

Here is the trap that catches projects which did everything else right.

Browsers cannot fetch ipfs:// natively, so the data reaches you through a gateway — an ordinary web server that speaks IPFS on one side and HTTPS on the other. Fine, until the pointer stored in the contract is written as a gateway URL rather than as an ipfs:// address.

When the pointer says https://somegateway.io/ipfs/bafy…, the collection depends on that one company staying online, even though the underlying data is perfectly content-addressed and might be pinned in a dozen places. The guarantee exists and the contract does not use it.

Store ipfs:// and let each client pick a gateway. Then any gateway will do, and no single one can take the collection down.

Checking a collection in five minutes

Read the pointer. On a block explorer, call tokenURI for any id. Note the scheme: https:// to a project domain is the weakest case; https:// to a gateway is content-addressed data with a single point of failure bolted on; ipfs:// or ar:// is what you want; data: means it is on-chain and you can stop reading.
Follow it. Fetch the metadata JSON and look at the image field, which is frequently stored differently from the metadata itself. A collection with IPFS metadata pointing at a server-hosted image has the weakest link of the two.
Ask who pins it. A team that has thought about this can tell you which service, and often that there is more than one. A team that has not will treat it as an odd question.
Check who can move the pointer. If the contract has an owner-only setBaseURI, durable storage still leaves one address able to point every token somewhere else.

If you are building

Pin to at least two providers, and treat a second copy on permanent storage as insurance rather than luxury — for most collections it costs less than the art did.

Store the content address in the contract, not a gateway URL. Publish the root CID somewhere outside your own site, so that a holder can restore the collection from the hash alone if you are no longer around to help. And when the reveal is done and the metadata is final, consider giving up the ability to change it: a contract that can no longer repoint is the only version of this promise that does not depend on you keeping it.

The chain will remember who owns token 412 long after everyone has forgotten who was paying for the pictures.