The ETH Address Checksum Validator answers one question about an Ethereum address: is the case of its letters the case EIP-55 prescribes? You paste an address, press Validate, and the tool hashes the address with keccak256, works out the canonical mixed-case form, and compares it letter for letter against what you typed. All of that runs in your browser: the keccak256 function is bundled into the page, nothing is uploaded, and the address never leaves your machine.
Paste an address and press Validate
There is no live checking: the input is read only when you press the Validate button. Press it on an empty input and the result is simply the red Invalid address format state, not a crash and not a special message. When the input passes the format gate, the tool compares your string letter for letter against the checksummed form, and the result is either Valid checksum, when the two are identical, or Valid format checksum mismatch, when the letters are right but the case is not.
The format gate: 0x plus exactly 40 hex digits
The gate is a single regular expression with three demands. The address must start with a lowercase 0x prefix: a capital X is rejected even though everything after it is fine. It must then carry exactly 40 hexadecimal characters, which makes the whole string 42 characters long; one digit short or one digit over both fail. Finally, leading and trailing spaces are trimmed before the check, so a copy that dragged in padding around the address still passes, while a space anywhere inside the string is a non-hex character and fails.
How EIP-55 decides each letter's case
Once the format is valid, the tool computes the canonical form. It strips the 0x prefix, lowercases the 40 hex characters, and feeds that string into keccak256, which returns a 64-character hex digest. Then it walks the address position by position: for each of the 40 positions it looks at the corresponding character of the digest, and if that digest digit has a value of 8 or more, meaning 8, 9, or any of the letters a through f, the address letter at that position becomes uppercase; otherwise it stays lowercase. Roughly half the letters end up uppercase, and which ones are decided entirely by the hash.
What the three result states mean
A green Valid checksum means your string is byte for byte the canonical mixed-case form, the form EIP-55 was designed to produce. A warning state, Valid format checksum mismatch, means the 40 hex digits are all correct but at least one letter has the wrong case; the address still points at the same account, it just fails the spell-check. An all-lowercase address is the classic example of the mismatch state: the format is valid, the checksum never matches. The same goes for a lowercase 0x followed by forty uppercase hex letters: the format gate passes, but the canonical form always starts with a lowercase x in its prefix, so the two can never be equal. A string with a capital X prefix does not even reach the comparison, because the prefix rule alone already fails it.
The three copies you can take
When the format is valid, three result cards appear, each with its own copy button. The first shows the whole string in lowercase. The second shows it in uppercase, and because the conversion applies to the entire string, even the prefix becomes 0X, a form you should not paste into a wallet. The third shows the EIP-55 checksummed form, the one worth copying: it is the address with a case that carries its own validity certificate.
Why the case matters at all
On the chain, case carries no meaning: lowercase, uppercase, and mixed case are the same account, because an Ethereum address is 20 bytes and letter case is not part of those bytes. The checksum exists for the human side of the transaction. Sending to a mistyped address is unrecoverable, and EIP-55 turns roughly half the letters into case-sensitive check digits, so a mistyped or transposed character usually produces a string whose checksum does not match, and wallets and exchange forms can reject it before the money moves.
What is not here, and where to go next
The tool is deliberately narrow: one input, one button, no stored history, and no swap control, because there is nothing to swap. If you want to see the hash that drives the case decisions, the Keccak-256 Hash Generator computes the same keccak256 digest on any input you choose. If you work with the other hash families, the Hash Generator covers them, and if your Ethereum work is about encoding function calls and data rather than addresses, the ABI Encoder/Decoder handles that side, while the ABI encoder walkthrough goes through the same keccak256 pipeline from the encoding direction.