Address format validator
Paste an address and see which chain it belongs to and whether the format holds up. It cannot catch "the address is real but belongs to the wrong person" — it does catch the two most common accidents: a paste that went wrong, and the wrong chain.
Verdict
—
Paste an address to begin.
What it actually checks, and what it cannot (expand)
What gets verified
- Tron and Bitcoin Base58Check — the string is decoded, the length and version byte are checked, and the four-byte checksum is recomputed with a double SHA-256. A transposed or dropped character fails here.
- Bitcoin bech32 and bech32m — the full checksum polynomial is computed, the encoding variant is identified, and the witness version is checked against the program length and the required variant. Mixed-case strings are rejected, because the specification requires that.
- Ethereum-style (0x…) — format only: the 0x prefix and 40 hexadecimal characters. See the limitation below.
The Ethereum limitation, stated plainly
An Ethereum-style address has no mandatory checksum. EIP-55 defines an optional one encoded in the letter casing, and verifying it requires Keccak-256, which this page does not implement. So for a 0x… address the tool confirms the shape and nothing more.
There is a second, more important limit for this family: Ethereum and BNB Chain use the same address format, so no amount of inspection of the string can tell you which network the recipient expects. That has to come from the recipient. The network picker asks that question first for exactly this reason.
A correction that changed the behaviour of this page
An earlier version checked bech32 addresses by appearance only — prefix, character set and length — without computing the checksum. That produced a specific wrong answer: BIP 173 explicitly lists mixed-case bech32 strings as invalid and supplies test vectors for them, and a character-set check happily calls such a string "correctly formatted". A string the specification requires you to reject was being reported as fine.
It now performs the full bech32 / bech32m checksum computation and checks that the witness version and program length are consistent, and mixed case is rejected outright. The implementation on this page was run against the test vectors published with BIP 350 before it shipped: the eight valid addresses decode to exactly the scriptPubKey bytes the specification lists, and the invalid ones — wrong checksum variant, out-of-range witness version, program length outside 2–40, a v0 program that is neither 20 nor 32 bytes, mixed case, and bad bit padding — are each rejected with the specific reason rather than a generic failure.
What it cannot tell you
- Whether the address exists or holds anything. A validator computes; it does not query a chain. Any well-formed string passes, whether or not anyone controls it.
- Whether it belongs to the right person. This is the actual risk and no format check touches it. Compare the first and last characters against the source you were given, and be aware that clipboard-hijacking malware substitutes a valid address for a valid address.
- Whether a memo or tag is required. That is a property of the receiving platform, not of the string.
- Which network to use for a 0x… address. As above.
Where the data comes from
Everything happens in your browser. The page connects to no chain, no explorer and no API, and what you paste is never sent anywhere or stored — closing the tab discards it. The checksum computation uses the browser's built-in Web Crypto interface; in an environment without it, the tool says the checksum was not computed rather than pretending it passed.
Related reading
- Which chain to withdraw USDT on — why the wrong chain is the expensive mistake
- Network picker — settle the chain before the address
- Wallet versus exchange account — where these addresses come from