Crypto Wallet Address Validator

It means the string is well formed and internally consistent: the characters belong to the right alphabet, the length matches the type the prefix declares, and the checksum built into the address agrees with the rest of it. That is all it means. It does not mean the address exists, that anyone holds the private key for it, that it has ever received funds, that it is on the chain you think, or that it belongs to the person you are paying. None of those questions can be answered without asking a node, and this page asks nothing.

Because it is a valid address, just an undefended one. EIP-55 hides a checksum in the letter case, so an address written entirely in one case carries no checksum at all and a single mistyped character in it would go completely undetected. That is why this page reports four outcomes rather than two: lower case and upper case are marked as unchecksummed, mixed case is verified against the Keccak-256 hash, and a mixed-case address that fails is flagged as a typo or an alteration. If you have a choice, always circulate the checksummed form.

Every EVM chain shares the same twenty-byte address format, so the string cannot tell you. Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain and the rest all accept the same address, and the same private key controls it on all of them. That is convenient until it is not: sending a token to the right address on the wrong chain is one of the most common ways funds are lost, and no validator can warn you, because there is nothing wrong with the address. Confirm the network in your wallet, not in the address.

Not offline. The difference between an externally owned account and a contract is whether code is stored at that address, which is chain state rather than anything encoded in the string. A block explorer can tell you, and it matters: sending tokens to a contract that was not written to receive them is a well-known way to lose them permanently.

The character after bc1 is the witness version. A q is version 0, which is native segwit: forty-two characters for a single key and sixty-two for a script. A p is version 1, which is taproot. They also use different checksums. Version 0 uses the original bech32 constant from BIP-173, and version 1 and above use bech32m from BIP-350. The change was deliberate: it means an old wallet that only knows bech32 will reject a taproot address rather than silently mangle it, so both constants are implemented here and a mismatch is reported as its own error.

Base58 is Base64 with the confusable characters removed. Zero and capital O look alike in many fonts, as do capital I and lower-case l, and the plus and slash of Base64 break when an address is double-clicked or wrapped in a URL. Bech32 makes the same trade differently, dropping 1, b, i, and o from its alphabet and using lower case throughout, which is also why a bech32 address is never mixed case: the checksum is computed over one case, so a mixed string cannot be verified at all.

Almost certainly a substitution rather than a typo. Clipboard-hijacking malware watches for something that looks like an address and replaces it with the attacker's own, which is a perfectly valid address and passes every check on this page. Address-poisoning attacks work similarly, seeding your transaction history with a lookalike so a later copy from the wrong row still validates. A checksum only detects corruption, never a swap. The defence is verifying the address out of band, comparing the whole string rather than the first and last four characters, and sending a small test amount first.

Not as valid targets, but they are recognised well enough to be named. A Litecoin address decodes as Base58Check with a version byte that is not Bitcoin's, and an ltc1 address has a human-readable part that is not bc, so both come back saying which chain they belong to rather than a bare rejection. Solana and Monero use different encodings entirely and will come back as an unrecognised format. Bitcoin and the EVM chains are what this page verifies.

A WIF private key is recognised by its version byte and stopped with a warning rather than a verdict, because that string can spend your coins and should never be typed into a website, including this one. Nothing is transmitted either way, since the page makes no requests, but the safe habit is absolute: a receiving address is public and can be pasted anywhere, while a private key or a seed phrase should only ever be entered into your own wallet software. This tool never generates keys, seed phrases, or addresses. It only reads what you paste.

No. Keccak-256, SHA-256, and the bech32 polynomial are all implemented in the page itself, so validation is pure arithmetic that runs in your tab. There is no explorer lookup, no RPC endpoint, no analytics on the input, and no wallet connection. A batch of two hundred customer addresses is checked without any of them leaving your machine, which is the main reason to use a local validator rather than pasting a payout list into a search box.