Some address formats identify a network through a prefix, length or checksum; others, especially EVM addresses, do not. This tool identifies the format family, checks what the format allows it to check, and states when the intended network cannot be recovered from the address.
Or try one of these
What this page actually does
It is worth being exact, because a tool that overstates what it checked is worse than no tool.
- Bitcoin, legacy formats. Decodes base58, verifies the four-byte checksum by hashing the payload twice with SHA-256, and reads the version byte to tell a public key hash from a script hash.
- Bitcoin, native segwit and taproot. Decodes bech32 and bech32m, verifies the BCH checksum, extracts the witness version and program length, and checks that the encoding matches the witness version — because version 0 must use bech32 and versions above it must use bech32m.
- EVM addresses. Checks the shape, and where the address is mixed case, verifies the EIP-55 checksum by computing Keccak-256 of the lowercase form. A mixed-case address that fails is flagged.
- TRON. Decodes base58check and confirms the 0x41 version byte and the twenty-one byte length.
- Solana. Confirms the string decodes to exactly thirty-two bytes of base58. There is no checksum in the format, so there is nothing further to verify — and the page says so rather than implying it validated something.
- XRP. Recognises the pattern only. The XRP Ledger uses a different base58 alphabet from Bitcoin's, which this page does not implement, so it reports the shape and states plainly that the checksum was not checked.
Everything runs in your browser. The hash functions are implemented in the page's own JavaScript rather than called from a service, so no address you paste leaves your machine, and the tool works with the network disconnected.
Why addresses look the way they do
Every address format is an answer to the same three questions, and the answers differ.
How do you stop a typo becoming a loss?
Bitcoin's original answer was base58check: hash the payload twice, take four bytes, glue them on the end. Change any character and the recomputed hash will not match. Four bytes is a strong enough check that random errors essentially never slip through.
Bech32's answer is better: a BCH error-correcting code, chosen so that up to four character errors are always detected and more errors are detected with overwhelming probability. It is also designed to be robust to the specific mistakes people make when reading characters aloud or copying by hand.
Ethereum's original answer was none at all. The format was defined without a checksum, which is why EIP-55 had to retrofit one using capitalisation — the only channel available that would not break existing software. Solana's answer is also none, and unlike Ethereum's there is no retrofit.
How do you stop characters being confused for each other?
Base58 is base64 with the ambiguous characters removed: no digit zero, no capital O, no capital I, no lowercase l. That decision comes from a world where people read addresses out loud and wrote them on paper.
Bech32 goes further and uses a 32-character alphabet chosen so that the pairs people actually confuse are not both in it. It is also all lowercase by convention, which means the address can be written in uppercase for a QR code, where uppercase encodes in fewer bits.
How do you say which network this is?
Base58check uses a version byte, which is why Bitcoin addresses start with 1 or 3 and TRON addresses
start with T. Bech32 uses an explicit human-readable prefix — bc for Bitcoin mainnet, and
each chain picks its own.
The EVM format says nothing. There is no network marker, so the same forty hex characters are a valid address on Ethereum, on every EVM layer 2, and on a long list of other chains. That convenience is also a common source of transfer errors: the address is valid everywhere, so nothing warns you that you picked the wrong network. Solana has the same gap for a different reason — the address is just a public key, with nothing wrapped around it.
What the format cannot tell you
A valid address is not a safe address. The checksum confirms the string was not mistyped. It says nothing about whether the address belongs to who you think, whether the account exists, or whether the recipient can actually receive what you are about to send.
Three specific gaps worth naming:
- Which network was meant. For EVM addresses this is not recoverable from the address at all. It is a decision the sender makes on the withdrawal screen.
- Whether a memo or tag is needed. Some networks pair an address with a second field, and exchanges commonly use one address for many customers. The address alone does not tell you.
- Whether it is a wallet at all. On Solana, wallets, token mints and programs all use the same encoding. On EVM chains, contracts and externally owned accounts look identical.
If you are moving assets between networks and want the fuller picture of what goes wrong, the guide on layer 1 and layer 2 covers the practical checklist.
Format details were checked against BIP-173 and BIP-350 for bech32 and bech32m, EIP-55 for the Ethereum checksum, and TRON's own account documentation, in August 2026. The SHA-256 and Keccak-256 implementations in this page are tested against published vectors before release; the test lives alongside the site source and is not part of what gets served.
Related tools: on-chain fee models · consensus mechanisms compared