An NFT appears in a wallet with an image and a description. That presentation can hide several separate components: the token record, metadata describing it and the file displayed as artwork. They do not necessarily live in the same place.
Understanding the storage arrangement is a technical reading task, not evidence that an item is a sound investment or that its creator owns every right associated with the image.
Follow the reference carefully
Ethereum’s ERC-721 documentation describes a token standard with a metadata extension. A token can refer to information outside the blockchain rather than embedding all of the displayed media directly in its record.
Ask where the metadata is stored, where the image or other media is stored and whether those references can change. A marketplace’s cached preview is not necessarily the original file or a promise that the file will remain available.
Separate permanence claims into questions
- What exactly is recorded on-chain?
- Who controls the referenced location or any update mechanism?
- What service keeps the media accessible?
- What happens if the website, gateway or project stops operating?
Different storage systems have different properties. A content-addressed reference and an ordinary website URL are not identical, but neither label alone explains every availability dependency. Read the actual project’s documentation rather than treating “decentralised” as a complete technical answer.
For a fictional example, the token may remain visible in a block explorer while its image URL returns an error. That would not mean the blockchain record disappeared; it would mean one part of the presentation is unavailable.
Do not connect a wallet just to read a claim
Use public documentation and read-only inspection where possible. Be cautious with unfamiliar links, downloads and requests to sign messages. A site asking for a signature to “repair” missing artwork deserves particular scrutiny.
Keep ownership, copyright, storage and market value as separate questions. Buying a token does not automatically settle all four. The useful conclusion is a clear map of what exists, where it is stored and which promises depend on someone continuing to operate a service.