Most people think an NFT is a picture. It is not. On Ethereum, the token is closer to a numbered entry in a ledger, and that entry usually holds a single line of text: a link. Follow the link and you often find a small file, which holds a second link. Only that second link leads to the artwork.

So the thing you own is a deed to an address, and the address points to another address. Either one can go dead. This article shows you how to trace each hop, how to tell a fingerprint from a street address, and where the real debates are.

The three hops between your wallet and the image

Start with the token. The ERC-721 standard defines a function called tokenURI. It takes a token ID and returns a string, and that string may point to a JSON file that follows a metadata schema. Marketplaces rely on it. OpenSea, for example, reads token metadata from the URI that this function returns.

The JSON file is the second hop. It is usually a small table with a title, a type, an image link, and some properties. The image link is the third hop, and it is the one you actually look at.

A research team that studied 12,353 Ethereum NFT contracts described this chain bluntly. Most NFT assets live off the blockchain, and NFTs bind their on-chain identifiers to them through multi-stage URLs. The researchers call that a weak binding, and it easily breaks the tie between the token and its asset.

The non-obvious part: the standard expected this

It is tempting to treat broken NFT images as a bug that sloppy projects introduced. The standard tells a different story. The authors of ERC-721 explained their reasoning with an example. They considered an NFT representing ownership of a house, where metadata such as the image and occupants can naturally change. A house gets repainted and sold to new tenants. The metadata should be able to follow.

They also weighed the alternative and rejected it. Putting all metadata for each asset on the blockchain was judged too expensive. The metadata extension itself is optional, too. The standard marks it as OPTIONAL.

This is the root of the “deed to an address” problem. The design was built around a changeable pointer, and art collectors then used it for work that is supposed to stay the same. One critic put the consequence harshly: in almost every art NFT, no control of the artwork is transferred to you, so you are buying a web link. That is a pointed reading, and not everyone accepts it. Many collectors value provenance, scarcity and community, which do not depend on the file. Still, the narrow technical point holds. The token does not contain the picture.

An address versus a fingerprint

This is where the type of link matters most. A normal web link (https://) tells a computer where to ask. Whoever runs that server decides what comes back, today and next year. If they change the file, the link still works and shows something else. If they close the account, it shows nothing.

A hash-based link works differently. On IPFS, the identifier is called a CID. It is a unique hash derived from the file’s contents. The same content uploaded twice produces the same CID, and changing even one byte produces a different one. A CID also does not describe a place. It does not indicate where the content is stored.

That gives you something a URL cannot. A client can hash what it receives and confirm it matches the CID it asked for. If your metadata link is a CID, nobody can quietly swap the file behind it. The swap would produce a different CID.

Here is the catch that most explainers skip. A fingerprint proves what a thing was. It does not keep the thing alive. IPFS is a content-addressing protocol, not a permanent storage guarantee. If every pin lapses, the content can become unreachable even though its CID remains valid. Pinning means a node agrees to keep the data. By default, IPFS nodes garbage-collect cached content over time.

So the honest comparison is this. A URL gives you a place but no proof. A CID gives you proof but no place. Neither gives you a promise.

How to trace your own NFT in ten minutes

You do not need to write code. You need a block explorer and a little patience.

1. Get the contract address and token ID. Any NFT page on a marketplace shows its owner, the smart contract address and the token ID.
2. Read the token’s link. Query the contract on Etherscan using the Read Contract tab. Enter your token ID into tokenURI. It returns the URI, which is usually a link to the NFT’s metadata.
3. Read the prefix. See the next section.
4. Open the metadata file. For an ipfs:// link, you can use an HTTP gateway. Gateways accept normal web requests for IPFS CIDs and serve the content back over HTTP.
5. Find the image field and read its prefix too. This is the step people skip. The two links are independent. One can be solid while the other is fragile.
6. Ask who can change the first link. This is harder to answer. More on it below.

What the prefix tells you

• https:// and a company or project domain. A regular https:// URL typically means centralized hosting. Whoever controls that server controls your image.
• ipfs://. This means IPFS. Content is verifiable. Availability depends on pinning.
• An https:// link with /ipfs/ in the path. This is a gateway link. The CID inside is still a fingerprint, but the domain in front is just one door to it.
• https://arweave.net/. This means Arweave.
• data:application/json;base64, This means the metadata is fully on-chain.

Do the check on both layers. A review of the research above describes 48 collections that appear decentralized in their metadata but rely on centralized assets. A tidy first hop can hide a fragile third one.

Three places the chain can fail

1. The token’s link gets rewritten

Many people assume that a CID in the contract settles things. It does not, if the contract lets its owner set a new URI. OpenSea notes that even when files are stored in a decentralized way, the creator can often make a transaction and change the metadata tied to an NFT. The fix is a “frozen” state. On OpenSea, once you freeze an NFT, you cannot unfreeze it or change its metadata.

There is a real debate over how far a freeze goes. OpenSea itself says it is tricky to know whether an NFT’s metadata is frozen, because there are usually several ways to change it. One independent writer argued that nothing stops a collection owner from changing the base URI, and wondered whether a freeze only holds inside one marketplace. Is the metadata really “frozen” if it is only applicable on OpenSea? That is one writer’s analysis of one collection, so treat it as a question to ask and not a verdict. The practical lesson is to check the contract and not just a badge.

2. The metadata file disappears

This one hurts most, because everything else hangs from it. NFT.Storage, a storage provider, ran an analysis with a partner. It argued that if the metadata goes missing, it does not matter how well your image is backed up, because the metadata has the final say. They reported that 12.8% of metadata assets linked from the Ethereum blockchain were missing. The source sells storage, and the data is from 2022, so read the number as a signal and not a current rate.

3. The image link dies or was never durable

The academic numbers point the same way. One study found that the assets of 25.24% of Ethereum NFT contracts were not accessible. Its authors conclude that under the existing off-chain settings, owning an NFT does not really mean possessing the asset. Decentralized storage did not rescue everything either. Only 33.77% of the decentralized assets in the study could be fully retrieved, according to a review of the paper. The likely reason is unpinned files, which fits the point about pinning above.

The permanence debate

If hashes need hosts, who should host? Three camps argue about it.

• Pin it on IPFS. It is cheap and flexible. You can switch pinning providers without changing the CID or breaking any link. That portability is a real advantage over a URL. The weakness is that someone must keep paying or keep a node running.
• Pay once on Arweave. Its backers say the one-time fee and the endowment cover storage costs for 200 years, even if storage costs do not fall. Skeptics point to the assumptions behind that. The model relies on economic assumptions about future storage costs.
• Put it on-chain. The metadata is embedded as a base64-encoded JSON blob that in turn contains a base64-encoded SVG. There is no outside file to lose. The cost is real, as the standard’s authors noted. High-profile on-chain projects exist, like Nouns, but they are a small fraction of the ecosystem. Also, SVG code suits some art and not others.

None of these is free of trade-offs. Which one is right depends on the work, the artist’s budget and how long you expect the piece to matter.

What a careful collector does

Before you buy, run the trace above. Write down the prefix of each link. A piece with an ipfs:// or Arweave metadata link and an image on the same system is in better shape than one that points at a project’s own server. Ask whether the contract owner can still change the URI.

After you buy, consider doing something about it. IPFS providers say a buyer can pin the CID of the token’s metadata and image to a pinning service or a node they control. That only works if the links are CIDs to begin with. For a plain web link, the best you can do is save a copy of the file and keep a record of what the token pointed to on the day you bought it.

The token will keep working as a record of who owns what. The question this article helps you answer is whether the record still points at the work. You can check that, and you can check it now.

Sources

• ERC-721: Non-Fungible Token Standard
• Do NFTs' Owners Really Possess their Assets? A First Look at the NFT-to-Asset Connection Fragility
• Decentralizing NFT metadata on OpenSea
• IPFS Docs: Pin using the command line (CIDs explained)
• Data integrity and $345 million worth of missing NFTs (NFT.Storage)
• Mutable Metadata (Brainflow)
• NFT Metadata Explained: On-Chain vs Off-Chain (NFT Bowl)
• IPFS and content addressing, explained without the mythology
• What Is Arweave (AR)? Permanent Data Storage
• What are CIDs? (Pinata Docs)