Crypto Address Validator

What this tool checks, and what it cannot

Two different questions hide behind "is this address valid". The first is whether the string is well formed: right length, right alphabet, checksum intact. That question has a definite answer, and this page answers it in your browser without sending the address anywhere. The second is whether the address exists, holds a balance, or belongs to the person who gave it to you. No offline checker can answer that, and any tool claiming to is reading a blockchain, not the string.

The distinction matters because the two failure modes look nothing alike. A malformed address is caught here and by every wallet, so a typo in a TRON address is an inconvenience rather than a loss. A well-formed address that belongs to the wrong person is invisible to every checker ever written.

TRON: Base58Check, verified down to the checksum

A TRON address is 34 characters and starts with T. Behind that string are 25 bytes: one version byte, 20 address bytes, and a 4-byte checksum. The version byte is 0x41 on mainnet, and it is the reason every address renders with a leading T once the 25 bytes are Base58-encoded.

The checksum is the first four bytes of SHA-256(SHA-256(payload)), where the payload is the version byte plus the 20 address bytes. This page computes that hash for real, using the browser's own Web Crypto API, and compares it against the four bytes carried in the address. A single altered character produces a different payload, a different hash, and a mismatch. That is the whole mechanism, and it is why a mistyped TRON address is rejected rather than accepted into a void.

Base58 also leaves four characters out of its alphabet on purpose: zero, capital O, capital I and lowercase l. They are the pairs people confuse when reading an address aloud or copying it by hand, and removing them means those confusions cannot produce a different valid address. If the checker reports a character outside the alphabet, one of those four is usually the culprit.

One thing the format does not tell you: whether the address is a wallet or a token contract. Both use the identical T-prefixed form on TRON. USDT's contract, TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, is a valid address by every check on this page, and sending a deposit to it is still a mistake. The TRC20 address page covers that distinction and the hex notation in more detail.

Ethereum and BSC: one format, two chains

An EVM address is 0x followed by 40 hexadecimal characters, 42 characters in total. Ethereum, BNB Smart Chain, Polygon and Arbitrum all use it, because they share the same execution layer and the same key derivation. That has a consequence worth stating plainly: there is no such thing as telling an ERC-20 address apart from a BEP-20 address by looking at it. The string is the same. What differs is the network you broadcast the transaction to, and the balances that exist on each chain.

This is where most cross-chain losses come from. An address that is perfectly valid on Ethereum is equally valid on BSC, so a wallet will happily send BEP-20 tokens to an address the recipient only monitors on Ethereum. The funds are not gone, they sit on the other chain, but recovering them needs the private key and a wallet configured for that network. The ERC20 address page and the BEP20 address page go through the practical side of that, including how BEP-20 differs from the older BEP-2 format, which starts with bnb1 and is not interchangeable with anything here.

EIP-55: the checksum hidden in capitalisation

Hex is case-insensitive, so 0xab… and 0xAB… address the same account. EIP-55 puts that spare capacity to work: hash the lowercase address with Keccak-256, and let each nibble of the hash decide whether the corresponding hex letter is written upper or lower case. The result looks like an ordinary mixed-case address and carries roughly four bits of error detection per letter.

So a mixed-case EVM address is making a claim, and an all-lowercase or all-uppercase one is not. Both are legal input for every wallet and every node. Only the mixed-case one can be checked.

This page reports which of the two you pasted, and stops there. Verifying the EIP-55 checksum needs a Keccak-256 implementation, and the browser's Web Crypto API does not offer Keccak — it offers SHA-256, which is what the TRON check above uses. Rather than ship a hand-written hash function for a security-relevant check, the tool tells you what it did not verify. If your address came from a wallet UI it almost certainly carries a correct checksum already; if it came out of a database or a log file, a full EIP-55 verification is worth running in your own code, where a vetted library is one import away.

Where addresses come from in an integration

Validating a pasted address is the last line of defence. The earlier one is not pasting addresses at all. In a payment or payout flow, deposit addresses are generated per customer and watched programmatically, so no human ever retypes one and the format question never arises.

That is the job the TRON API and the equivalent Ethereum and BSC endpoints do: create an address, register a webhook for it, credit the deposit when the notification arrives. Addresses stay non-custodial, and the trial runs seven days with no credit card and no KYC. Two operational details are worth knowing before you build on it: webhooks have no automatic retry, so a failed delivery is fetched with POST /<chain>/webhooks/notifications/failed rather than waiting for a redelivery, and Solana has no webhook support at all.

The other calculators on this site are listed on the tools overview.

FAQ

Does the address leave my browser?

No. The Base58 decoding and the SHA-256 hashing both run locally, through the browser's Web Crypto API. There is no request to a server, which also means the tool works with the network disconnected.

What exactly is verified for a TRON address?

Four things: that the string is 34 characters, that every character is in the Base58 alphabet, that it decodes to 25 bytes with the version byte 0x41, and that the trailing four bytes match the first four bytes of SHA-256(SHA-256(payload)). The checksum is computed, not assumed.

Can you tell an ERC-20 address from a BEP-20 address?

No, and neither can anything else. The two standards use the identical 0x plus 40 hex character format. A tool that claims to distinguish them is either guessing or querying a blockchain for balances, which is a different question from address validity.

Why is the EIP-55 checksum not verified?

It needs Keccak-256, which the browser's built-in crypto does not provide, and this page does not ship a hash implementation of its own for a check people would rely on. What the page does report is whether the address is written in mixed case, meaning it carries an EIP-55 checksum, or in a single case, meaning it carries none.

Does a valid address mean the funds will arrive?

No. Validity is a property of the string. Whether the address is monitored, whether it is on the chain you are sending from, and whether it belongs to the intended recipient are all separate questions that no offline check can settle.

Why does Base58 skip some characters?

Zero, capital O, capital I and lowercase l are excluded because they are easily mistaken for one another. Leaving them out means an ambiguous reading cannot silently produce a different valid address.

What is the hex form of a TRON address?

The same 21 payload bytes written as hex: 41 followed by 40 hex characters. The TVM uses that form internally, wallets show the Base58Check form. The hex form carries no checksum, so there is nothing to verify in it.

Is a contract address a valid address?

Yes, by every format check. On TRON and on EVM chains, contract addresses and wallet addresses are indistinguishable by shape. Sending a deposit to a token contract passes validation and still loses the funds, which is why address validation is a formatting check rather than a safety check.