ERC-20 vs ERC-721: What’s the Difference?

Almost every token you encounter on Ethereum follows one of a small number of standards, and two dominate the conversation: ERC-20 and ERC-721. They are often mentioned together, which can make them seem interchangeable. They are not. One describes tokens that are all alike, the other describes tokens that are each unique. Understanding the split clears up a lot of confusion about what a token actually is and how wallets know how to display it. This article compares the two, from the idea of fungibility down to the functions they define.

What a token standard is

A token on Ethereum is not a coin sitting in a file; it is an entry managed by a smart contract. A standard like ERC-20 or ERC-721 is an agreed interface: a set of functions and events a contract promises to implement so that any wallet, exchange, or explorer can interact with it predictably without needing to know the specifics of that particular project. That shared vocabulary is what makes tokens interoperable. If you are new to contracts generally, what a smart contract is and isn’t sets the stage.

The letters themselves are worth decoding. “ERC” stands for Ethereum Request for Comments, the label given to application-level standards proposed by the community. The number is just the identifier assigned when the proposal was filed, which is why ERC-20 predates ERC-721: 20 came first. A standard becomes influential not because anyone is forced to use it but because so many wallets and services build around it that following it is the path of least resistance. A contract can technically implement its own token logic however it likes; what it gains by conforming to a standard is instant compatibility with everything already built to expect that interface.

ERC-20: fungible tokens

ERC-20 defines a standard for fungible tokens. The documentation explains that they “have a property that makes each Token be exactly the same (in type and value) as another Token,” so one token is always equivalent to another of the same kind. This is the same property that makes ordinary money work: any one unit is as good as any other. ERC-20 is the standard behind most project tokens, stablecoins, and similar assets.

The standard was proposed by Fabian Vogelsteller in November 2015 as Ethereum Request for Comments 20. It specifies a core interface that a compliant contract must expose:

• totalSupply() — the total number of tokens in existence
• balanceOf(address) — the balance held by an account
• transfer(address, uint256) — move tokens to another account
• transferFrom(address, address, uint256) — move tokens on someone’s behalf
• approve(address, uint256) — authorise a spender up to an amount
• allowance(address, address) — check how much a spender may still move

It also defines two events, Transfer and Approval, which contracts emit so that off-chain tools can track movements and authorisations. Events are how a contract announces that something happened; wallets and explorers listen for them to update balances and histories without having to re-run the contract’s logic themselves.

Because ERC-20 tracks a balance per address, it is naturally divisible: you can hold and send fractional amounts. A key detail is that the balance is just a number in the contract’s storage, and the standard leaves the number of decimal places up to the project through a common (though not strictly required) decimals value. This is why one token might display to many decimal places while another shows none. The underlying model is always the same: the contract keeps a ledger of who holds how much, and the functions above are the only sanctioned ways to change it.

ERC-721: non-fungible tokens

ERC-721 defines a standard for non-fungible tokens, or NFTs. As the documentation puts it, an NFT “is used to identify something or someone in a unique way.” Instead of an interchangeable balance, each ERC-721 token is a distinct item. That suits use cases such as collectibles, membership passes, or any record where individual identity matters.

The standard was proposed by William Entriken, Dieter Shirley, Jacob Evans, and Nastassia Sachs in January 2018. Its defining idea is the token identifier: each NFT has a uint256 variable called tokenId, and “the pair contract address, uint256 tokenId must be globally unique.” That pairing is what makes one specific token distinguishable from every other, even within the same collection.

ERC-721’s core functions reflect ownership of individual items rather than balances:

• balanceOf(address) — how many tokens an address owns
• ownerOf(uint256) — who owns a specific token
• safeTransferFrom() and transferFrom() — transfer a specific token
• approve() — authorise a transfer of one token
• setApprovalForAll(), getApproved(), isApprovedForAll() — manage operator permissions

It defines the events Transfer, Approval, and ApprovalForAll. Metadata such as a name or image is typically referenced through a token URI extension, keeping the on-chain record lean while pointing to richer details elsewhere.

That last point is a common source of confusion. For most NFTs, the image and description are not stored on the blockchain itself; the contract stores the unique token identifier and a link to where the metadata lives. Whether that link points to durable, content-addressed storage or to an ordinary web server has real consequences for how permanent the associated media is. The blockchain guarantees who owns token number X in a given contract; it does not, by default, guarantee that the picture X points to will always be reachable. Distinguishing the on-chain ownership record from the off-chain content it references is essential to understanding what an NFT actually is.

Fungible versus non-fungible, side by side

The approval model, and its risk

Both standards let you authorise someone else to move your tokens, which is essential for how applications work: a marketplace or exchange needs permission to move tokens on your behalf. In ERC-20 this is approve and allowance; in ERC-721 it is approve for a single token and, more powerfully, setApprovalForAll for every token you hold in that contract.

That power is exactly why approvals are a common attack surface. A malicious or deceptive request can ask you to grant broad spending or operator rights, and a granted approval persists until you revoke it. We cover this in depth in token approvals: the risk nobody explains and explain the countermeasure in how to revoke token approvals. Phishing that abuses these functions is broken down in signature phishing: permit, approve, and setApprovalForAll.

Why the standards matter

The real payoff of standardisation is interoperability. Because ERC-20 and ERC-721 contracts expose the same functions, a wallet can show your balances and holdings, an explorer can label transfers, and an application can integrate a new token without custom code. This is why a token that follows the standard “just works” across the ecosystem, and why a contract that deviates can behave unexpectedly. Verifying that a token behaves as its standard implies is part of due diligence; see how to verify a contract address. Newer designs such as smart-contract wallets build on these same interfaces, as explained in what is a smart contract wallet.

Choosing between them, and what comes next

The right standard follows from the nature of the thing being represented. If every unit should be interchangeable and divisible, a currency, a set of points, a claim on something measured by quantity, then a fungible design in the ERC-20 mould fits. If each item must be individually identifiable, a specific membership, a numbered edition, a record tied to one thing, then a non-fungible design in the ERC-721 mould fits. Asking “are two of these the same or not?” almost always answers the question.

Both standards have also inspired successors that address their limits. Some later designs let a single contract manage many distinct token types at once, blending fungible and non-fungible behaviour, which is efficient for applications that mint large numbers of related items. Others extend the base interfaces with extra features such as richer approval controls. None of this displaces ERC-20 and ERC-721; rather, it builds on the same conventions, which is exactly why understanding the two originals makes the rest of the ecosystem legible. When you meet a new token, the first useful questions are which standard it follows and whether its contract genuinely implements that standard as advertised.

The takeaway

ERC-20 and ERC-721 answer the same question, “how should a token behave,” for two different kinds of asset. ERC-20 governs fungible tokens, where every unit is identical and tracked as a divisible balance. ERC-721 governs non-fungible tokens, where each item carries a unique identifier and is owned individually. Both rely on a shared interface that makes tokens portable across the ecosystem, and both use approval mechanisms that deserve care. Knowing which standard a token follows tells you, at a glance, whether you are dealing with something interchangeable or something one of a kind.

Sources

• ERC-20 Token Standard — ethereum.org
• ERC-721 Non-Fungible Token Standard — ethereum.org
• EIP-20: Token Standard — Ethereum Improvement Proposals
• EIP-721: Non-Fungible Token Standard — Ethereum Improvement Proposals