What is ERC-721?

ERC-721 is a set of interface standards used on Ethereum to track individually numbered tokens. Tokens of this kind are usually called non-fungible tokens (NFTs): every number within the same contract can be identified and transferred separately, unlike a fungible token where a balance accumulates by amount and only the number of units matters.

ERC stands for Ethereum Request for Comments, the category for Ethereum's application-layer standards and conventions; 721 is this proposal's number. The standard lets wallets and applications know how to query who currently holds a given number, how to transfer it, and how to authorize other addresses to act on a holder's behalf.

How an individual number identifies a token

Every ERC-721 contract can manage many token numbers, that is, tokenId values. A number only has meaning inside that contract, so identifying a token on the same network requires using both the contract address and the number; checking across networks also requires the network name.

For example, token number 7 in contract A and token number 7 in contract B are not the same object. Even if two tokens display the same name or image, their onchain records remain independent as long as the contract addresses differ.

A number itself also guarantees nothing about rarity, authenticity or value. A developer can use sequential numbering, random numbering or another allocation method; the standard only requires that a specific number be distinguishable, and it does not explain the commercial meaning behind a number.

How holding records are queried

ERC-721 offers two queries that are easy to confuse:

• ownerOf queries which address a given number currently belongs to;
• balanceOf queries how many of that contract's tokens an address holds.

The balance here is a count of tokens, not a sum of numbers, and it does not mean those tokens are equal in value. To know which specific numbers an address holds, the basic balanceOf is not enough; an application can read history and current state to build an index, or use an optional enumeration feature a contract separately provides.

What gets transferred is a specified number

When transferring an ERC-721 token, the operation must state the sending address, the receiving address and the specific number. On success, the contract updates that number's holder and emits a Transfer event, letting wallets, block explorers and data services recognize the change.

ERC-721 specifies both an ordinary transfer and a safe transfer. transferFrom moves a specified number directly to the target address; when the target is a contract, safeTransferFrom additionally checks whether that contract confirms, as agreed, that it can receive ERC-721 tokens. Without a correct confirmation, a safe transfer fails, which reduces cases where a token gets stuck after being moved into a contract unable to handle it.

A "safe transfer" only checks whether a receiving contract supports this receiving flow. It does not judge whether the receiving address belongs to the intended person, and it does not verify a token's content, a transaction price or the trustworthiness of an external project.

Approving a single number versus approving everything

A holder can let another address or application operate tokens on their behalf, but ERC-721 splits approval into two scopes.

approve designates an address permitted to operate one specific number; getApproved queries that number's current individual approval. Once the number is transferred, this individual approval is cleared.

setApprovalForAll instead hands all of a holder's tokens in that contract to an operating party; isApprovedForAll is used to query this blanket approval. It does not merely approve the numbers currently held — it may also affect tokens of the same contract acquired later, until the approval is revoked.

When the approval for a single number changes, the contract emits an Approval event; when a blanket approval changes, it emits an ApprovalForAll event. Wallets and data services can update their records accordingly, but the actual approval is still determined by the contract's current state.

A blanket approval does not transfer tokens away immediately, but the approved party gains a very wide scope of operation. Users need to check the approved address and the contract address; merely disconnecting a wallet from a website usually does not revoke an approval already written onchain.

Metadata connects a number to descriptive information

The basic holding and transfer interfaces handle only numbers and addresses. ERC-721's optional metadata extension can supply a token name, a ticker, and a tokenURI that returns the location of descriptive information.

That location may point to onchain data, or to a file on a website or in distributed storage. The file usually then contains a name, a description and an image address. Whether a wallet can display the image depends on whether it supports the relevant format, and on the link and file remaining accessible.

So an NFT existing onchain does not mean the image itself is necessarily stored onchain. Metadata may also be updated by a server, or become unreadable because a link stops working. Judging whether content can persist long term requires looking at the specific storage method and at whether the contract allows the location to be changed.

How the standard lets applications recognize an interface

ERC-721 requires a contract to support an interface recognition mechanism. An application can ask a contract whether it declares support for a particular set of functions, then decide whether it can interact with it in the ERC-721 way.

ERC-165, another Ethereum interface standard, specifies this mechanism; its role is comparable to letting a contract answer "which interfaces do I support". It can help an application choose how to call, but it only reflects the contract's declaration and implementation — it cannot prove that token content is genuine or that code is free of defects.

Metadata and enumeration are optional extensions. A contract can support basic ERC-721 transfers yet provide no name, image link or complete list of numbers. A wallet should not treat an optional feature as a capability every ERC-721 contract necessarily has.

Differences from the fungible token standard

ERC-20 mainly records how many units each address owns; a transfer states an amount. ERC-721 mainly records which address each number belongs to; a transfer states a specific number.

Holding 3 ERC-721 tokens therefore only indicates 3 numbers; it does not mean the three are interchangeable or equal in value. By contrast, equal amounts of the same ERC-20 token are usually interchangeable as the contract keeps account of them, with no need to track each number separately.

Both kinds of standard can provide transfers and approvals, but their parameters and approval scopes differ. An application cannot use ERC-20 amount logic to handle ERC-721 numbers simply because function names look similar.

The standard does not prove offchain rights

What ERC-721 records are the numbers, holders and approval relationships within a contract. It does not by itself confirm who created a given image, and it does not automatically grant copyright, ticket admission, ownership of a physical object or other offchain rights.

A project can use a number to associate a collectible, a game item, a membership credential or another object, but whether that association is effective also depends on the issuance arrangements, usage rules, content provenance and applicable law. A change of onchain holder only proves that contract state changed; on its own it cannot prove that an offchain institution will recognize the same outcome.

Standard compatibility does not mean identical behaviour

A specific contract can add minting, destruction, pausing, lists, royalty indications, upgrades or other rules beyond the basic interfaces. ERC-721 does not uniformly specify how a token is first created, whether supply has an upper limit, or how a trading platform must charge fees, and it does not guarantee that every application will follow additional information.

When integrating or using a specific token, check the network, contract address, number, approval scope, metadata storage and administrative permissions. "ERC-721" is only a shared interface, not a certification of an issuer's identity, content authenticity, rarity or market value.

FAQ

Does every NFT use this standard?

No. Other networks have their own token models, and other NFT standards or custom interfaces also exist on Ethereum. You first have to confirm the network and which standard the specific contract supports.

Can a contract create only one NFT?

No. The same ERC-721 contract can manage many individual numbers, each recording its holder and approval state separately.

Does the same number mean the same NFT?

No. A number is unique only within a specific contract. The network, contract address and number all have to be checked together.

Can a safe transfer prevent sending to the wrong person?

No. A safe transfer mainly checks whether a receiving contract can accept ERC-721 tokens as agreed; it does not judge whether an address belongs to the intended recipient.

Does buying an NFT give you copyright in the image?

Not necessarily. ERC-721 does not specify copyright or other offchain licensing. Which usage rights a holder obtains requires reading the project's terms, its licence and applicable law.

Related concepts

Continue with token standard, crypto token, ERC-20 and smart contract, or return to the Crypto Glossary.

Sources

• ERC-721: Non-Fungible Token Standard — number and holder queries, transfers, approvals, events and optional extensions.
• Ethereum.org: ERC-721 introduction — the purpose of non-fungible tokens, contract recognition and common interfaces.
• ERC-165: Standard Interface Detection — the mechanism by which a contract declares and is queried for the interfaces it supports.