Token standards & NFTs

NFT metadata standard

An NFT on-chain is mostly just an id and an owner; everything that makes it feel like a collectible — its name, its picture, its traits — lives in a metadata document the token points to. The metadata standard is the shared JSON shape of that document, so that any wallet or marketplace can display any NFT without bespoke code. ERC-721's optional metadata extension defines tokenURI(tokenId), which returns a URI; fetch that URI and you get the JSON.

The widely-followed schema (popularized by OpenSea on top of the ERC-721/1155 metadata extensions) has fields like name, description, and image (a URI to the artwork), plus an attributes array of objects each with a trait_type and value, which is what powers rarity rankings and trait filters. The image URI can point to centralized HTTPS, to IPFS via an ipfs:// link, or be embedded inline; the JSON itself can likewise be hosted anywhere or returned directly by the contract.

The crucial subtlety is that the standard governs the shape, not the storage or the permanence. tokenURI may return a fixed link, or it may be dynamic and change over time; the JSON may live on a company server that could go offline, on IPFS that needs pinning to survive, or fully on-chain. So two NFTs can both 'follow the metadata standard' yet have wildly different guarantees about whether their art will still exist in ten years — a distinction that separates on-chain metadata from a fragile centralized URL.

{
  "name": "Voyager #42",
  "description": "An on-chain explorer.",
  "image": "ipfs://bafy.../42.png",
  "attributes": [
    { "trait_type": "Background", "value": "Nebula" },
    { "trait_type": "Eyes", "value": "Laser" }
  ]
}

A typical NFT metadata JSON returned by tokenURI.

Following the metadata standard guarantees that the JSON is shaped correctly, not that the image behind it will still load. Always check where the image URI actually points.

Also called
tokenURI metadatatokenURI 元資料