Web3 tools
Token Decimal Checker
Read decimals, symbol and total supply directly from an ERC-20 contract, then convert between the amount a person types and the raw integer a contract expects. Getting this wrong is how transfers end up a million times too large.
Paste a token contract address to read its decimals.
Decimals you will actually meet
| Decimals | Tokens | 1 token stored as |
|---|---|---|
| 6 | USDC, USDT | 1,000,000 |
| 8 | WBTC, cbBTC | 100,000,000 |
| 18 | ETH, DAI, LINK, UNI | 1,000,000,000,000,000,000 |
| 0 | Some game and points tokens | 1 |
Related tools
- ABI Decoder — decode the calldata that carries these raw amounts.
- Wallet Balance Viewer — native balances and ENS resolution across 12 chains.
- Wallet Address Checker — validate an address offline before sending.
Frequently asked questions
Why do token decimals matter so much?
Contracts store balances as plain integers with no decimal point; decimals() only says where to display one. USDC uses 6 decimals, so 1 USDC is stored as 1000000. WBTC uses 8 and most tokens use 18. Assume 18 for a 6-decimal token and you are off by a factor of a trillion, which is the single most common cause of a transfer sending far more or far less than intended.
Is 18 decimals a safe default?
No. It is the most common value and the ERC-20 suggested default, but it is not required by the standard and major tokens deviate. USDC and USDT use 6, WBTC uses 8, and some tokens use 0. Always read decimals() from the specific contract on the specific chain rather than assuming, because the same token can even differ between chains.
The tool says this is not an ERC-20. What does that mean?
The contract did not respond to decimals() and totalSupply(). Usually it is an NFT contract — ERC-721 and ERC-1155 have no decimals because tokens are indivisible — or a proxy that does not forward those calls, or simply not a token contract at all.
Why does the name show correctly for older tokens like MKR?
A handful of pre-standard tokens declare name and symbol as bytes32 instead of string. Decoding those as ABI strings fails or produces garbage, so this tool tries the string form first and falls back to a trimmed bytes32. MKR is the best-known example and reads as Maker here rather than as an empty field.
Can I trust the converter with very large numbers?
Yes. Conversion uses string arithmetic rather than JavaScript numbers, so a full 78-digit uint256 stays exact. This matters because JavaScript loses integer precision above roughly 9 quadrillion, which is well below the values a token with 18 decimals produces routinely.