NFT metadata is the structured information that defines what an NFT actually represents — its name, description, image URL, and the attributes or traits that determine rarity and appearance. The token itself, as recorded on-chain, is an ID number tied to a smart contract. The metadata is the layer that tells you what that token is supposed to be.
This distinction matters in practice. What you see on a marketplace is usually the metadata, rendered. What the blockchain actually holds is a reference to where that metadata lives. If the metadata moves, changes, or disappears, your NFT remains on-chain — but the information it represents may not.
How NFT Metadata Actually Works
The standard for Ethereum NFTs — established by ERC-721 and extended by ERC-1155 — specifies that each token has a tokenURI() function. Call that function with a token ID, and it returns a URI: typically a URL or IPFS content hash pointing to a JSON file.
That JSON file follows a convention most major collections use: a name field, a description, an image field (usually another URL), and an attributes array — the list of traits that determine things like background color, accessory type, or rarity tier. Some collections encode all of this directly into the contract. Most store only the JSON pointer on-chain and host the JSON (and the image) externally.
Three Ways to Check NFT Metadata
The most direct method is reading the tokenURI from the contract itself.
On Etherscan, navigate to the contract address, go to the Contract tab, then Read Contract. Find the tokenURI function, enter the token ID, and execute. The returned value will be one of three things: a URL (starting with https://), an IPFS URI (starting with ipfs://), or a Base64-encoded string — which means the metadata is stored on-chain. If it returns an IPFS URI, paste the CID into an IPFS gateway like ipfs.io/ipfs/{CID} to retrieve the JSON.
The second method is marketplace APIs. OpenSea exposes metadata at https://api.opensea.io/api/v2/chain/{chain}/contract/{address}/nfts/{identifier}. The response includes rendered traits and the image URL. This is faster but indirect — you're reading what the marketplace cached, not the live contract state. If the metadata updated recently, the marketplace may be showing stale data.
The third method applies to fully on-chain NFTs. Some contracts (Nouns DAO is the well-known example) store SVG images encoded as Base64 directly in the token URI. In those cases, tokenURI returns a data URI you can paste into a browser address bar to render the image and read the raw JSON immediately. No external request required.
Where the Risk Actually Lives
The most important thing to check isn't the metadata content itself — it's where the metadata is stored.
A metadata URI starting with https://api.exampleproject.com/tokens/1 is hosted on a centralized server the project controls. If they shut it down, change the content, or go out of business, the metadata may change or disappear. The on-chain token survives, but what it represents can shift without any on-chain signal.
An IPFS URI (ipfs://Qm...) is content-addressed: the CID is a hash of the content itself. Change the content, and the CID changes. That means a mismatch would be detectable. But IPFS content isn't guaranteed to persist — it requires active pinning. If nobody is pinning the content, it can become unavailable even though the URI is correct.
Arweave (ar://) offers stronger persistence. Files stored on Arweave are paid for upfront as a permanent storage fee, with no ongoing maintenance required. It's a different durability model than IPFS.
Fully on-chain metadata — image and JSON encoded directly into the contract — is the most resilient. It can't disappear because it's part of the contract bytecode itself.
There's one more constraint worth checking: whether the tokenURI function is updateable. In many contracts, the contract owner can change what tokenURI returns. Unless the contract is verified as immutable and the owner key has been burned or renounced, a project team could theoretically update what the token represents. Looking at the contract source code on Etherscan for a setTokenURI setter function tells you whether that possibility exists.
What's Changing
Marketplace metadata display is slowly improving. OpenSea and some aggregators have begun surfacing storage type in collection views, making it easier to see at a glance whether an NFT's assets are on IPFS or a centralized server. This isn't consistent yet.
Metadata durability has become a more visible concern after several early NFT projects had centralized servers go offline, leaving holders with tokens whose images are now broken URLs. IPFS and Arweave storage are increasingly common defaults for new collections, though centralized hosting still exists widely.
Cross-chain metadata standards are less consistent than on Ethereum. ERC-721's tokenURI convention has been adopted across EVM-compatible chains (Polygon, Base, Arbitrum), but Solana and other non-EVM networks use different metadata formats and storage conventions. The process described here applies primarily to EVM-chain NFTs.
Confirmation and Invalidation
Confirmation signals: tokenURI returns a content-addressed URI (IPFS or Arweave); the JSON is accessible and its content matches what the marketplace displays; no setTokenURI or owner-controlled update function visible in the contract source.
Invalidation signals: the URI returns a 404; the marketplace image doesn't match the IPFS content; the contract has an updateable tokenURI function under active owner control; Base64 output doesn't decode to valid JSON.
Timing
Now: if you're evaluating an NFT before purchasing or transferring, check the storage type. Centralized URIs represent a different risk profile than content-addressed ones.
Next: marketplace metadata display is improving but inconsistent. Cross-chain standards are fragmented and will take time to converge.
Later: fully on-chain NFTs remain a small subset of all collections. As Ethereum scaling reduces storage costs, more on-chain metadata becomes feasible — but it's not common practice today.
Boundary
This covers how to read and evaluate NFT metadata technically. It doesn't address how to value NFTs based on traits, how metadata relates to intellectual property rights, or on-chain standards outside EVM-compatible networks. Solana NFTs use a different metadata structure and require different tooling.
