The image is usually the first element a user notices when viewing an NFT. It appears in the wallet, marketplace listing, collection page and social preview.

However, the image is not the complete NFT record.

An NFT is identified on a blockchain by its smart contract and token ID. The contract can then return a metadata reference containing the information that marketplaces and wallets use to understand and display the asset.

That metadata may define the NFT’s name, description, media, attributes, licence references, product identifiers and stated utility. In a utility NFT, certificate, gaming item or phygital product, these fields can be more important than the visible artwork.

A high-quality image can attract attention. Well-structured NFT metadata explains what the token actually represents.

What is NFT metadata?

NFT metadata is structured information associated with a blockchain token.

For an ERC-721 NFT, the optional metadata interface includes a tokenURI function. That function returns a URI which may point to a JSON file describing the asset represented by the NFT. The original ERC-721 metadata schema includes three basic properties: name, description and image.

A simple metadata record may look like this:

{
  "name": "Digital Product Record #104",
  "description": "A verification record for a limited digital product.",
  "image": "ipfs://bafy.../preview.png"
}

Marketplaces can extend this structure with attributes, animation files, external links and other fields. OpenSea, for example, retrieves ERC-721 metadata from tokenURI and uses the resulting data to display the NFT’s name, media, description and traits. The URI may resolve to external JSON or return JSON stored directly on-chain.

The image is therefore commonly one value inside the wider metadata document.

The token, metadata and media are separate layers

An NFT product can be understood as several connected layers.

The blockchain token

The blockchain records the contract address, token ID, current owner and transfer history.

The metadata reference

The contract returns a URI or generates data explaining what the token represents.

The media or underlying asset

The metadata may point to an image, video, audio file, document, software record, 3D model or another resource.

The legal and utility terms

Separate documents may explain copyright, licensing, access, redemption, membership or product conditions.

These layers can use different storage systems and different permissions.

A token may remain safely recorded on-chain while its externally hosted image disappears. Metadata can remain available while the service described in it stops operating. The NFT can transfer successfully even when the holder receives no copyright in the related artwork.

This is why users should not evaluate an NFT only through its thumbnail.

Metadata determines how marketplaces display an NFT

NFT marketplaces do not normally infer the asset’s meaning from the blockchain transfer record alone.

They query the contract for metadata and use the returned fields to build the listing page. OpenSea’s current developer documentation states that token metadata controls the displayed name, media, description and traits. It supports metadata returned as valid JSON from an external URI or embedded on-chain.

This means that poorly structured metadata can cause:

• missing images;
• incorrect token names;
• unusable filters;
• broken animations;
• inconsistent traits;
• incorrect collection presentation;
• incomplete product information.

Two NFTs can use the same token standard but provide very different levels of information.

One may contain only a generic image and title. Another may document the asset category, issuer, version, utility, hash, licence status and verification reference.

The second record is more useful even when its artwork is visually simpler.

An NFT image does not prove what the token represents

A digital image can be copied and reused.

A person can create a new NFT that points to another creator’s public artwork. The resulting blockchain token may be technically valid even though the issuer lacks copyright or authority.

The image alone does not establish:

• who created the work;
• who authorised tokenization;
• whether copyright was transferred;
• whether the NFT is part of the official collection;
• whether a physical product exists;
• whether the stated utility is active;
• whether the metadata has changed;
• whether the issuer’s declarations are accurate.

A credible NFT record should connect the visible media with additional identifiers and declarations.

Depending on the project, these may include:

• creator or issuer information;
• official contract address;
• asset hash;
• creation or release date;
• licence reference;
• physical serial number;
• verification-page URL;
• redemption status;
• software version;
• product category.

These fields do not guarantee that every claim is legally correct. They make the claim identifiable and easier to review.

Metadata provides context for utility NFTs

A utility NFT needs to explain more than what it looks like.

The metadata or connected documentation should help the holder determine:

• what benefit the NFT activates;
• who provides that benefit;
• how the benefit is accessed;
• whether it expires;
• whether it transfers with the token;
• which conditions apply;
• what happens after redemption;
• which rights are excluded.

Consider a membership NFT.

Its image may display a membership card. The useful information is the membership tier, issuer, activation status, expiry rules and access conditions.

A software NFT may use an attractive product illustration. Its important metadata concerns the software version, licence category, update entitlement, issuer and file reference.

A physical-product NFT may show a photograph. Its meaningful fields include the manufacturer, model, serial number, custody status and physical identifier.

For these products, the image supports presentation. Metadata supports interpretation.

NFT metadata can link to intellectual products

Metadata can connect an NFT with a digital work without storing the complete work publicly on-chain.

An intellectual-product record may include:

• asset title;
• product type;
• creator declaration;
• release date;
• file hash;
• version identifier;
• storage reference;
• licence category;
• public verification record.

A cryptographic hash can help identify a specific file version. If the underlying file changes, its hash also changes.

The hash does not prove who created the file. It allows a later file to be compared with the recorded version.

This distinction is important for software, documents, music, research and other intellectual products. Metadata can provide a structured provenance reference without publishing confidential source materials.

NFT metadata can connect physical and digital products

A phygital NFT links a physical product with a digital record.

The physical connection may use:

• a QR code;
• NFC tag;
• secure chip;
• serial number;
• product certificate;
• custody record.

The metadata can identify the relevant physical product and describe the connection method.

Useful fields may include:

• manufacturer or authorised issuer;
• product model;
• unique serial number;
• production date;
• material or edition;
• physical tag type;
• current redemption state;
• inspection record;
• custody provider.

The metadata does not prevent a QR code from being copied or a physical tag from being removed. Physical authenticity depends on the complete issuance and verification system.

The role of metadata is to make that system understandable. It should identify the product and explain what the digital record does—and does not—confirm.

MekaVerse NFT presents these models through its offline NFT integrations framework.

Where NFT metadata can be stored

NFT metadata can use several storage architectures.

Conventional web servers

The token URI may point to a JSON file hosted through a normal HTTPS address.

This model is easy to implement and update. It also creates dependence on the project’s domain, server and account security.

If the website closes or the file is removed, the NFT may stop displaying correctly.

If the file remains mutable, the server operator may replace the metadata without changing the token ID.

Conventional hosting can be suitable for controlled dynamic products, but the issuer should disclose the dependency and maintain backups.

IPFS

IPFS uses content addressing. A Content Identifier, or CID, identifies content according to the data itself rather than only its server location. IPFS recommends using canonical ipfs:// URIs for NFT metadata and connected media instead of making one HTTP gateway the primary reference.

If a file changes, the new content produces a different CID.

This makes undetected replacement more difficult. A particular CID continues identifying the original content.

However, content addressing is not the same as guaranteed permanent hosting.

IPFS nodes can remove cached content through garbage collection. The official IPFS documentation recommends pinning important data to one or more nodes to support continued availability. It also warns that third-party pinning providers may stop maintaining their services.

A strong IPFS plan therefore includes:

• canonical IPFS URIs;
• reliable pinning;
• redundant storage providers;
• independent backups;
• documented responsibility for renewal and maintenance.

Simply uploading a file to IPFS once does not guarantee that it will remain retrievable forever.

On-chain metadata

Metadata can be generated or stored directly within the smart contract.

A contract may return a data URI containing JSON and embedded SVG media. OpenSea’s metadata documentation supports both external JSON and metadata returned on-chain.

On-chain metadata reduces dependence on a conventional server or gateway. It can also make the relationship between token state and displayed content easier to inspect.

The trade-offs include:

• greater development complexity;
• blockchain storage costs;
• limits on large media files;
• difficult correction of mistakes;
• dependence on the contract’s update permissions.

On-chain metadata can still be mutable where the contract includes administrator-controlled variables or upgrade functionality.

“Stored on-chain” should not automatically be interpreted as “unchangeable.”

Hybrid metadata

Many practical projects combine on-chain and off-chain information.

The blockchain may store:

• token identity;
• important status values;
• content hash;
• issuer address;
• metadata pointer.

External storage may contain:

• large images;
• video;
• product documents;
• software packages;
• detailed JSON records.

A hybrid design can balance verifiability and storage efficiency. It also creates more components that need to remain aligned.

The project should document which fields are authoritative and how inconsistencies will be resolved.

Mutable metadata is not automatically bad

Metadata updates can serve legitimate purposes.

A dynamic NFT may need to reflect:

• game progression;
• membership renewal;
• product redemption;
• corrected information;
• software updates;
• certificate suspension;
• physical-product inspection;
• evolving artwork.

The critical issue is whether the update model is transparent.

A project should explain:

• which fields can change;
• who can change them;
• what triggers the update;
• whether the holder can approve it;
• whether earlier versions remain reviewable;
• whether the change affects legal or utility rights.

Undisclosed mutability creates a different product from disclosed dynamic metadata.

A buyer purchasing a permanent artwork record has different expectations from a user receiving an evolving game character.

ERC-4906 helps platforms detect metadata changes

Marketplaces and wallets often cache NFT metadata.

Without a common update signal, each platform may need a collection-specific method to discover that the JSON data has changed.

ERC-4906 adds MetadataUpdate and BatchMetadataUpdate events. A compliant contract emits the relevant event when the JSON metadata for a token or token range changes. Third-party platforms can then query the token URI again and refresh the displayed information.

The standard does not contain the complete new metadata inside the event. It tells the platform that it should retrieve the latest record.

ERC-4906 also warns that functions used to trigger off-chain metadata updates require correct permission controls. An unprotected update function could allow unauthorised manipulation of the token display.

The standard improves indexing. It does not verify whether the update is truthful or authorised under the project’s legal terms.

ERC-7160 supports multiple metadata records

One NFT does not always need to use only one metadata URI.

ERC-7160 is a Final ERC-721 extension that allows multiple metadata URIs to be associated with one token. It can also identify a pinned primary URI. The standard lists metadata revision history, dynamic assets, different display formats and collaborative tokens among its intended applications.

This can support:

• historical versions;
• alternate artwork;
• different languages;
• marketplace and verification views;
• separate media formats;
• user-selected presentations.

Multiple metadata records can preserve context that would be lost through simple file replacement.

Applications still need to support the standard. A marketplace may display only the primary URI and ignore the wider history.

The project must also define who can add, remove or pin metadata choices.

Metadata integrity can be independently checked

Content-addressed storage is one method for connecting an NFT to a specific file.

Another approach is to publish a cryptographic digest that clients can use to test whether retrieved metadata matches an expected version.

ERC-2477 proposes functions for metadata and schema integrity. A compatible client can retrieve the specified hash algorithm and digest, calculate the hash of the metadata document and compare the result.

This does not guarantee that the metadata’s claims are true.

It confirms that the retrieved document has the expected contents.

Integrity and authenticity are related but different:

• Integrity asks whether the data has changed.
• Authenticity asks whether the data came from the claimed authorised source.
• Accuracy asks whether the statements inside it are correct.
• Availability asks whether the data can still be retrieved.

A strong NFT record needs to consider all four.

Metadata schemas improve interoperability

Wallets and marketplaces need predictable field names and formats.

OpenSea supports metadata structured according to ERC-721 and ERC-1155 conventions and uses additional fields for media and traits. Its current documentation instructs developers to return valid JSON and include the media and attributes that should appear in the marketplace interface.

Using recognised structures makes it easier for platforms to display:

• names;
• descriptions;
• images;
• animation files;
• trait categories;
• numerical values.

Custom fields can still be useful for specialist products, but general platforms may ignore them.

A utility NFT can therefore use two levels of metadata:

1. Standard fields for broad wallet and marketplace compatibility.
2. Extended project fields for verification, licensing or product-specific information.

The extended fields should remain documented publicly so that independent applications can interpret them.

Which metadata fields matter for a utility NFT?

A robust utility NFT record may include the following groups.

Token and asset identity

• asset name;
• record type;
• edition or version;
• creation or issue date;
• issuer declaration.

Media references

• preview image;
• animation or video;
• document reference;
• content format;
• content hash.

Utility information

• utility type;
• benefit provider;
• activation method;
• expiry conditions;
• transfer behaviour;
• redemption state.

Rights information

• copyright owner declaration;
• licence category;
• commercial-use status;
• separate licence reference;
• excluded rights.

Verification information

• contract address;
• blockchain network;
• token ID;
• product serial;
• physical tag reference;
• verification-page URL;
• current record status.

Storage information

• metadata URI;
• asset URI;
• storage protocol;
• CID or content hash;
• backup or persistence model.

Not every field belongs in public metadata. Personal, confidential and security-sensitive information should be excluded or stored through an appropriate protected system.

Metadata should not contain private keys or sensitive personal data

Public NFT metadata may be accessible through marketplaces, explorers, gateways and direct contract queries.

It is not an appropriate place for:

• private keys;
• wallet recovery phrases;
• passwords;
• authentication codes;
• confidential source files;
• unnecessary identity documents;
• private addresses;
• sensitive personal information.

Even mutable metadata may be copied, indexed or cached before removal.

Privacy planning must occur before tokenization, especially when the NFT is used for certificates, memberships or product records connected to an identifiable person.

The public record should contain the minimum information required to perform its intended verification or utility function.

Broken metadata can leave an empty token shell

An NFT can continue appearing in a wallet even when its associated content is unavailable.

This may happen when:

• the metadata server closes;
• the project domain expires;
• an IPFS file is no longer pinned;
• the gateway is unavailable;
• the JSON format becomes invalid;
• a linked media file is deleted;
• marketplace caching fails;
• the token URI contains an error.

The owner may still control and transfer the blockchain token.

What disappears is the accessible context explaining what that token represents.

IPFS documentation specifically distinguishes persistence from permanence. Cached data may be removed unless someone continues storing or pinning it.

This is why metadata maintenance is part of the NFT product—not a one-time minting task.

Marketplace images can differ from the authoritative record

A marketplace may cache an older image or apply its own media processing.

Different platforms may also support different metadata fields or file formats.

As a result, the same NFT can appear differently across:

• marketplaces;
• wallets;
• blockchain explorers;
• issuer websites;
• verification pages.

The authoritative review should begin with the official contract and its current metadata reference, not with a screenshot or social-media post.

Where metadata is dynamic, the user should also inspect relevant update events and project documentation.

MekaVerse NFT’s NFT verification service reviews the public token identifiers, metadata references and available supporting information rather than treating the marketplace image as sufficient evidence.

Metadata does not transfer copyright

A metadata description can state that a token includes commercial rights. That statement is not automatically a legally effective copyright transfer.

Copyright ownership and licensing depend on applicable law and the relevant agreement.

A complete NFT project may reference a separate licence defining:

• permitted personal use;
• commercial-use limits;
• reproduction rights;
• derivative works;
• sublicensing;
• termination;
• rights following transfer.

The metadata can help users locate and identify that licence.

It should not replace clear legal terms with a short marketing claim.

The distinction between token ownership and intellectual-property ownership is explained further in the MekaVerse NFT Intellectual Property Policy.

How buyers should inspect NFT metadata

Before acquiring or relying on an NFT, a user should review more than the displayed image.

Confirm the token identity

Check the official contract address, token ID and blockchain network.

Inspect the token URI

Determine where the metadata comes from and whether the URI points to HTTPS, IPFS, on-chain data or another system.

Open the JSON record

Review the actual name, description, media references, attributes and external links.

Check storage dependencies

Identify whether the files rely on one server, one gateway or an actively maintained IPFS pin.

Determine mutability

Review whether the contract or issuer can change the token URI or underlying data.

Review utility and rights

Confirm what the holder receives and whether the full terms exist outside the marketplace description.

Verify the issuer

Compare the contract and metadata against official project sources.

Avoid sensitive disclosures

Never submit private keys or recovery phrases to view, verify or update metadata.

A professional-looking image is not a substitute for these checks.

How NFT projects should structure metadata

Before minting, a project should create a metadata specification.

The specification should answer:

1. Which standard fields will be used?
2. Which project-specific fields are required?
3. Where will the JSON be stored?
4. Where will the media files be stored?
5. Who is responsible for long-term persistence?
6. Can the record change after minting?
7. Which events will signal an update?
8. How will historical versions be preserved?
9. Which information must remain private?
10. How will independent users verify the asset?

The metadata should be tested in common wallets and marketplaces before a public launch.

Projects should also test what happens when:

• an IPFS gateway fails;
• an external image is unavailable;
• metadata is updated;
• a token moves to another wallet;
• a physical product is redeemed;
• a licence or membership expires.

A structured project can be submitted through the MekaVerse NFT tokenization request page.

Frequently asked questions about NFT metadata

Is NFT metadata stored on the blockchain?

It can be, but it often is not. An ERC-721 contract commonly returns a URI pointing to external JSON. Metadata may also be returned directly on-chain.

Is the NFT image stored inside the token?

Usually, the token or its metadata points to the image through a URI. The image may be stored on a server, IPFS or directly on-chain.

Can NFT metadata change?

Yes. The contract or external storage architecture may allow updates. ERC-4906 provides standard events that notify applications when JSON metadata changes.

Does IPFS make NFT files permanent?

Not automatically. A CID permanently identifies specific content, but the content must remain stored and available through one or more IPFS nodes. Pinning supports continued persistence.

Can someone replace an IPFS file without changing the CID?

No. Changing the content produces a different CID. The contract or metadata can still be updated to point to a new CID where the project has that authority.

Why does my NFT image not appear in a marketplace?

Possible causes include invalid JSON, unsupported media, inaccessible storage, an incorrect token URI or outdated marketplace caching. Marketplaces rely on the metadata returned by the contract to display the token.

Can one NFT have several metadata files?

Yes. ERC-7160 supports multiple metadata URIs for one ERC-721 token and allows a primary URI to be pinned.

Does metadata prove NFT authenticity?

No. Metadata records claims and references. Authenticity also depends on the authorised issuer, underlying asset, contract identity and available supporting evidence.

Does metadata define copyright ownership?

It can reference a licence or rights declaration, but token metadata alone does not automatically transfer copyright.

What metadata should a phygital NFT contain?

It may contain the product model, issuer, serial number, physical identifier type, token reference, custody or redemption status and relevant verification links.

Metadata is the operational identity of an NFT

The token image remains important. It gives the asset a recognisable visual representation and helps users discover it.

Metadata gives that image meaning.

It identifies the asset, organises its properties, connects supporting files, explains utility and allows wallets, marketplaces and verification systems to interpret the token consistently.

As NFTs move toward intellectual products, gaming items, memberships, certificates and phygital products, this structured information becomes more important.

A collectible image can survive with a minimal description.

A utility NFT cannot.

It needs metadata capable of explaining what the token represents, how the record can be checked, which benefits apply and where the underlying content will remain available.

The strongest NFT projects will not treat metadata as a technical form completed immediately before minting.

They will treat it as the operational identity of the digital asset.

Risk notice: This article is provided for general educational and informational purposes. It is not legal, technical, financial or investment advice. NFT metadata may be mutable, incorrectly configured or dependent on external storage providers. A blockchain token can remain accessible even when its associated media or utility is unavailable.