An NFT contract stores ownership, not artwork. What a wallet displays comes from a metadata file the contract points to, and the file has to match a structure the wallet expects.
The contract returns a pointer
A standard token contract exposes a function that returns a location string for a given token identifier. That string is the entire link between the token and anything visual.
The location may be an ordinary web address, a content-addressed reference on a distributed storage network, or data encoded directly into the return value.
Wallets fetch whatever sits at that location. If the response is missing, malformed or slow, the wallet has nothing to render and typically falls back to a placeholder.
The expected structure is a convention
The retrieved file is normally JSON containing a name, a description, an image reference and a list of attributes. None of this is enforced by the token standard itself.
Wallets and marketplaces converged on the shape used by early large collections, and that convention became the practical requirement for being displayed correctly.
A collection that names its fields differently, or nests the image under an unexpected key, is fully valid on chain and simultaneously invisible in most interfaces.
Attributes drive more than trait lists
The attributes array is what marketplaces read to build trait filters and rarity views. Its formatting determines whether traits are treated as categories or as numeric ranges.
Declaring a numeric trait as a plain string turns it into hundreds of separate categories, which breaks range filtering without producing any error.
Because attribute handling differs between platforms, the same collection can present usable filters on one venue and unusable ones on another with no change to the contract.
Where the file lives decides whether it lasts
A pointer to a server controlled by the project depends on that server continuing to run and continuing to return the same content.
Content-addressed storage removes the substitution risk, since the address is derived from the file's contents and any change produces a different address entirely.
It does not remove the availability risk. Someone must keep the data pinned and served, or the address remains valid while resolving to nothing.
Caching hides problems until it does not
Marketplaces cache metadata and images aggressively, because fetching them on every page view would be slow and expensive at scale.
A collection whose source has already gone offline can therefore continue displaying normally for a long period, with the failure surfacing only when a cache is refreshed.
Checking a collection's durability means resolving the pointer directly rather than trusting a storefront, since the storefront may be showing a copy of something that no longer exists.