Ethereum Address Checksum Tool (EIP-55)

Why address checksums matter

An Ethereum address is the last 20 bytes of the Keccak-256 hash of a public key, written as 40 hex characters. Nothing in that format carries error detection: any 40-character hex string is a syntactically valid address, and the network will happily move funds to one that nobody controls. EIP-55, proposed by Vitalik Buterin and Alex Van de Sande on 14 January 2016 and now Final, fixes this without changing the format at all. It uses the capitalization of the letters a to f to carry a Keccak-256 checksum, so the address still looks the same and still works the same, but software can flag a single mistyped character.

The specification estimates about 15 check bits per address, which puts the chance that a randomly generated address survives a typo and still passes the check at 0.0247%, roughly fifty times better than the older ICAP scheme it replaced. That is worth restating plainly: a passing checksum means the string was not garbled in transit, not that the address belongs to the person you think it does.

The algorithm, step by step

Strip the 0x prefix and lowercase the remaining 40 characters. Hash that ASCII string with Keccak-256, the same hash Ethereum uses for selectors and storage slots, which you can reproduce with the Keccak-256 calculator. Walk the address and the hash in parallel, one hex character against one hex nibble. Where the character is a letter and the nibble is 8 or greater, print it uppercase; otherwise leave it as it is. Digits 0 to 9 have no case, so they pass through untouched and contribute nothing to the checksum, which is why an address made mostly of digits protects you less than one full of letters. The two rows in the tool above are exactly these two strings, aligned.

Verification runs the same way round. Lowercase the address you were given, recompute the checksummed form, and compare it to what you were given character for character. Anything that differs is either a typo or an address that was never checksummed under plain EIP-55. Note the asymmetry: an all-lowercase or all-uppercase address cannot fail, since it never claimed a checksum in the first place. Only mixed-case input is a claim that can be checked, which is the reason the tool reports those two situations differently.

Checksumming in ethers.js, web3.js and beyond

Every serious Ethereum library ships this, and you should reach for it rather than hand-rolling the loop. On BLAZED.sh, ethers.js and web3.js are pre-installed in the script editor, so these run without any setup.

// ethers.js v6
import { getAddress, isAddress } from "ethers";

getAddress("0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed");
// -> "0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed"
getAddress("0x5aAeb6053f3E94C9b9A09f33669435E7Ef1BeAed");
// -> throws: bad address checksum
isAddress("0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed"); // true

// web3.js
import { utils } from "web3";

utils.toChecksumAddress("0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed");
utils.isAddress("0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed"); // true

// viem
import { getAddress } from "viem";
getAddress("0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed");

# Python, eth-utils
from eth_utils import to_checksum_address, is_checksum_address

to_checksum_address("0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed")
is_checksum_address("0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed")  # True

// Go, go-ethereum
import "github.com/ethereum/go-ethereum/common"

addr := common.HexToAddress("0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed")
addr.Hex() // "0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed"

Two traps worth knowing. Go's common.HexToAddress parses without validating, so it will silently accept a broken checksum and only Hex() gives you the correct casing back. And Solidity has no notion of this at all: an address is 20 raw bytes at runtime, so casing is a purely off-chain, human-facing concern. Do the check where the string is still a string, in your frontend or your bot, before the transaction is ever built.

EIP-1191 and other chains

EIP-1191 is the one variation you are likely to meet. It hashes the chain ID concatenated with the lowercase address instead of the address alone, so the same account renders with different capitalization on different networks and an address pasted from the wrong chain fails the check loudly. RSK adopted it for chain IDs 30 and 31. Ethereum mainnet did not, and neither did the EVM chains that follow mainnet conventions, so plain EIP-55 remains the interoperable default and is what this tool implements. If an address that you trust reports a mismatch here, an EIP-1191 origin is the first thing to rule out.

When you are about to send, the checksum is only half the check. Confirm the recipient from a second source, and if you want to know what the transfer will cost before you sign it, the gas fee calculator prices it against live mainnet conditions. If your own service validates addresses at scale, doing it next to the node rather than over a remote API is the whole point of running your code on BLAZED.sh.

Frequently asked questions