This note explains what NFT metadata is in plain terms, and why it matters more than most buyers expect. An NFT is not really the image. It is a token ID plus a metadata record, and that record is what a marketplace reads to show you a name, a set of traits, and the artwork itself. Understanding the metadata is how you stop treating an NFT as a picture and start reading it as a documented object.

The simplest way to picture it is as a catalogue entry. In an archive, the object on the wall is one thing and the index card describing it is another. The card records what the object is, what it is made of, and where it is kept. NFT metadata is that card. It is the documentation layer of a relic, not the relic itself.

An NFT is a token ID plus a record

When someone owns an NFT, what they actually hold on the blockchain is a token: a unique ID inside a specific contract. That token, on its own, is just a number that belongs to an address. It does not contain a picture. The picture, and everything that describes it, lives in the metadata the token points to.

So a single NFT is really two parts working together. The token is the proof of ownership, the entry on the ledger that says this ID belongs to this wallet. The metadata is the description, the file that says what the token represents. Separate the two and the structure becomes clear. The token is the registration number. The metadata is the record attached to that number.

This is also why the same word, NFT, can feel slippery. People point at the image and call that the NFT. Strictly, the image is one field inside the record the token references. The token guarantees who owns the entry. The record describes what the entry is.

What the metadata record actually contains

For most collections the metadata is a small JSON file. JSON is just a plain-text format for storing labelled values, readable by a person and by a machine. A typical record holds a handful of standard fields. The exact shape varies, but the common pieces are consistent enough to describe plainly.

  • name: what the piece is called, often the collection name plus a number, such as the relic's catalogue title.
  • description: a short text about the piece or the collection it belongs to.
  • image: a reference, a link, to where the actual artwork file is stored. The record points to the picture rather than containing it.
  • attributes: the list of traits, the part that makes one token different from another in a measurable way.

That fourth field is the one that does the most work, so it is worth slowing down on. The attributes are usually written as a list of trait type and value pairs. A trait type names a category, and the value is what that token has in that category. A piece might list a background, a material, a condition, and so on, each with its own value. Read together, those pairs are the structured description of the object, the part a machine can sort and compare.

The image field is worth one more note, because it surprises people. The metadata does not embed the artwork inside itself. It stores a reference to it, a location where the file lives. That location can be an ordinary web address, or it can be a content-addressed link on a system like the InterPlanetary File System, a decentralized storage network where a file is addressed by its content rather than by a server name (IPFS). Where the image and the metadata are stored matters for how durable the record is, which is a separate question from what the record contains.

Why metadata is what a marketplace reads

Here is the practical reason any of this matters. When you open a collection on a marketplace and see the artwork, the name, and a panel of traits down the side, you are not looking at the token. You are looking at the marketplace's reading of the metadata. The platform fetches the record the token points to, parses those fields, and renders them. The picture you see is the image field resolved. The trait panel is the attributes list laid out.

This is why metadata is the part that has to be correct. A token with a broken or missing image reference shows a blank where the art should be, even though the token itself is perfectly valid. A record with no attributes shows no traits, because there is nothing for the platform to display. The token can be entirely sound on the ledger and still present as empty if the record behind it is incomplete. The ownership is on the blockchain. The presentation comes from the metadata.

It also explains a quieter point about trust. Because the metadata is what gets read and rendered, the question of where it lives, and whether it can be changed after the fact, is a real one. A record that can be quietly altered is a different kind of object than one that is fixed. For a closed archive, the goal is a record that is set and stays set, so the catalogue entry you read is the catalogue entry that was sealed. That permanence is part of how an archive holds its shape over time.

How traits become the inputs to rarity

The attributes field connects directly to the question most people ask next, which is how some pieces end up rarer than others. The answer starts here, with the metadata. The traits listed in a token's record are the raw inputs a rarity method reads. Before anything can be scored or ranked, there has to be a structured list of what each token has, and that list is the attributes in the metadata.

In broad terms, a rarity method looks across every token's attributes, measures how common or uncommon each trait value is, and uses that to place tokens relative to one another. The metadata is the source data. The rarity method is the reading applied on top of it. If you want the general mechanics of how that scoring works across most collections, that is its own subject, covered in how is NFT rarity calculated.

One distinction is worth keeping in view, because it changes what the traits mean. In many collections the traits are assigned by a random mint, so the resulting rarity is an accident of distribution that nobody planned. In others, the categories that count are defined ahead of time, so rarity is a property of the design rather than a side effect of mint luck. The deeper contrast between those two approaches is covered in structural rarity vs hype rarity. The point for this note is narrower: in both cases, the traits in the metadata are where the reading begins.

This is also where we stop short on purpose. The specific categories Trash Relics records, how much each one counts, and the model that turns traits into a structural rank are not reproduced here. That model is owned and documented on the Rarity Architecture page, which is the source of record for it. This note explains what metadata is and where the traits come from. The scoring belongs to that page.

Metadata as the documentation layer of a relic

Pulling it back together: an NFT is a token ID plus a record, the record is usually a small JSON file holding a name, a description, a reference to the image, and a list of traits, and that record is what marketplaces read and what rarity methods score. The image is the visible part. The metadata is the part that makes it legible, sortable, and checkable.

For an archive, that framing fits naturally. Every relic is catalogued, and the metadata is the catalogue entry: the documented record of what the object is, sealed alongside the image rather than separate from it. If you want to see how the relics are organized and catalogued as a set, that is described on The Archive. The picture is what you look at. The metadata is what makes it a record rather than just an image.