Ever noticed that Ethereum addresses mix upper- and lowercase letters, like 0xd8dA6BF2…, in a pattern that looks random? It is not random. The casing is a checksum, defined by EIP-55, and it exists to catch typos before they cost someone their funds.
The problem: hex has no error detection
An Ethereum address is 20 bytes written as 40 hexadecimal characters. Raw hex is fragile: change any character and you get a different, but still perfectly well-formed, address. Bitcoin solved this from day one by building a checksum into its Base58Check format, so a mistyped Bitcoin address is almost always rejected outright. Early Ethereum had nothing equivalent: a one-character slip produced a valid-looking address whose private key nobody will ever hold.
Rather than switch to a new format and break every existing integration, Vitalik Buterin's EIP-55 (2016) found spare bandwidth hiding in plain sight: hexadecimal letters can be written in either case without changing their value. That case choice, one bit per letter, became the checksum channel.
How the checksum works
The algorithm fits in three sentences. Take the address in all-lowercase (without 0x) and hash it with keccak-256, Ethereum's native hash function. Walk the 40 address characters: digits (0-9) are left alone; letters (a-f) are uppercased if the corresponding hex digit of the hash is 8 or higher, lowercased otherwise. The result is the canonical, checksummed form of the address.
Verification is the same walk in reverse: recompute the hash and check that every letter's case matches what the hash dictates. One flipped character changes the required casing pattern almost everywhere, so the mismatch is caught immediately, locally, with no network access. That is exactly what our validator does in your browser.
How much protection do you get?
A 40-character address contains on average about 15 letters, and each letter carries one bit of checksum. A random typo therefore slips past the checksum with probability around 1 in 2¹⁵, roughly 1 in 32,000, versus certain acceptance with plain hex. Not cryptographic-grade protection, but transformative for its actual job: catching fat fingers, OCR errors, and copy-paste truncation.
Three casing states are worth telling apart. Mixed case that matches the hash: valid, checksummed, safe to trust the transcription. All-lowercase (or all-uppercase): valid but unprotected; the checksum is simply absent, which is common for addresses generated programmatically. Mixed case that does not match: reject it. Either a character was corrupted or the casing was mangled; both mean "do not send funds here".
EIP-55 across the EVM world
Because the algorithm depends only on keccak-256 and the address bytes, it works unchanged on every EVM chain: Polygon, BNB Chain, Arbitrum, Base all share it. A sibling proposal, EIP-1191, mixes the chain ID into the hash so that a checksum is only valid for its intended network; it never achieved broad wallet adoption, so in practice the same EIP-55 form circulates everywhere.
One quirk to know: because the checksum is case-based, tools that lowercase addresses for comparison (a common and correct practice for equality checks) are destroying the checksum, not the address. Displaying an address should re-derive the EIP-55 form; comparing two addresses should normalize case first. Confusing those two operations is a recurring source of bug reports.