Blockchain fundamentals
NFT metadata: where the image and its description actually live
Follow the token’s reference to its metadata and media, then check who can change each layer and who keeps it available.
Research articles and reference entries are published in English. Navigation is available in seven languages.
In this article
Start with the contract and token ID
A marketplace image is the end of a lookup process. For an ERC-721 token, first identify its contract and token ID. The standard’s optional metadata extension includes tokenURI, which can return a reference to a JSON document. That document may contain a name, description and another reference for an image. The token, descriptive document and media file can therefore be separate records. ERC-721 defines the interface, not a promise that every collection uses the same storage system.
IPFS and content addressing: authenticity is not persistence →
Inspect the layers separately
For a concrete investigation, write down the chain, contract address, token ID and observation time. Preserve the returned URI and metadata response. Then follow the media reference and record what was actually returned. This sequence helps distinguish a contract change, an updated metadata document and a failure at the image server.
A broken marketplace thumbnail does not by itself establish that the token disappeared. Equally, a transferable token does not establish that its associated artwork remains retrievable. Avoid replacing either question with a screenshot of the other.
A content identifier is not a storage subscription
An ordinary HTTPS address names a location whose response can change. IPFS uses content addressing, but a file still needs providers that retain and serve it. Its documentation describes pinning as a way to protect retained content from garbage collection on participating nodes. Pinning services and their funding can disappear; a familiar gateway URL is not a guarantee of permanent availability. See the IPFS persistence guide.
Practical questions follow from this distinction: Who pins the metadata? Who pins the media? Are there independent copies? What happens if the collection’s operator stops paying? A content-addressed reference helps identify a particular version; it does not answer all of those operational questions.
Find the authority to change the reference
Read the implementation and its administrative controls. Is the metadata location fixed, can an authorised account update it, or can the contract be upgraded? A statement that metadata is “frozen” needs an identifiable mechanism and a defined scope. Saving one response today does not establish which changes remain possible tomorrow.
ERC-4906 adds optional metadata-update events so applications can refresh their displays. An update event is a notification mechanism. It is not a promise that the content is immutable or that a marketplace has already refreshed its cache.
Keep ownership and licence questions separate
ERC-721 describes a token interface. Copyright, commercial-use permissions, access to a game and a promise of future delivery require their own terms and evidence. Keep the applicable licence alongside the technical snapshot rather than inferring all rights from a wallet balance.
For a reusable record, save the original response bytes, the retrieval time, a hash of the retrieved file, the relevant contract state and the licence you consulted. A screenshot is useful context, but it does not replace those records. Continue with evidence snapshots, IPFS content addressing and the NFT market’s history.