# Ethereum Vanity Address Format: Hex Characters and EIP-55 Checksum

Source: https://www.ethvanity.com/blog/ethereum-vanity-address-hex-checksum

Published: 2026-11-02

Updated: 2026-11-12

![Hex and checksum. Address: 0x + 40 hexadecimal characters; Pattern: Only 0-9 and a-f are available; Case: EIP-55 encodes a checksum in letter case.](https://www.ethvanity.com/images/blog/ethereum-vanity-address-hex-checksum-diagram-v2.webp)

Hex and checksum. Address: 0x + 40 hexadecimal characters; Pattern: Only 0-9 and a-f are available; Case: EIP-55 encodes a checksum in letter case.

[Full-size diagram (SVG)](https://www.ethvanity.com/images/blog/ethereum-vanity-address-hex-checksum-diagram-v2.svg)

[Diagram download (PNG)](https://www.ethvanity.com/images/blog/ethereum-vanity-address-hex-checksum-diagram-v2.png)

An Ethereum address is 20 bytes shown as 0x plus 40 hexadecimal characters, so a vanity pattern can only use 0-9 and a-f. Capital letters are not chosen freely: EIP-55 uppercases a letter only when the matching nibble of keccak256(lowercase address) is 8 or higher, so each letter in a case-sensitive pattern roughly doubles the expected search work.

## The 16-character alphabet of an Ethereum address

An Ethereum account address is the last 20 bytes of a Keccak-256 hash, which the ethereum.org accounts documentation describes as the rightmost 160 bits. Written in hexadecimal, 20 bytes become exactly 40 characters, and the conventional 0x prefix only marks the string as hex. The prefix is not part of the 20-byte value and cannot be matched by a vanity search.

Each hex character encodes 4 bits (a nibble), so the alphabet has 16 symbols: the digits 0-9 and the letters a-f. Any pattern containing g-z, such as ETH, NFT or HELLO, can never appear in an address no matter how long a generator runs. Creators work around this with leetspeak substitutions: 0 for o, 1 for l or i, 5 for s, 7 for t and 8 for b are common choices.

Because the address is the output of a hash, every one of the 16 symbols is equally likely at every position. That uniformity is what makes difficulty easy to calculate: a specific character at a fixed position has a probability of 1/16, and the full method is covered in [how hard an Ethereum vanity address is to find](https://www.ethvanity.com/blog/ethereum-vanity-address-difficulty).


| Wanted word | Possible in hex? | Workable spelling |
| --- | --- | --- |
| cafe | Yes | cafe |
| dead beef | Yes | deadbeef |
| face | Yes | face |
| boss | No (o, s) | b055 |
| coffee | No (o) | c0ffee |
| eth | No (t, h) | No close hex spelling |


## How the EIP-55 checksum algorithm works

EIP-55, written by Vitalik Buterin and Alex Van de Sande in 2016, adds error detection without changing the address value. The algorithm takes the 40 lowercase hex characters, hashes them as ASCII text with Keccak-256, and walks through both strings side by side. Digits are left alone. A letter is uppercased when the hash character at the same index is 8, 9, a, b, c, d, e or f, and stays lowercase when it is 0-7.

Note that the input to the hash is the text of the lowercase address without 0x, not the 20 raw bytes. Hashing the bytes instead is a common implementation bug that produces a different, invalid capitalization.

- Step 1: lowercase the 40 hex characters and drop the 0x prefix.
- Step 2: compute keccak256 over those 40 ASCII characters, giving 64 hex characters.
- Step 3: for each index i from 0 to 39, if address[i] is a letter and hash[i] is 8 or higher, write it in uppercase.
- Step 4: prepend 0x to the result.

## Worked example with an EIP-55 test vector

Take the first test vector listed in EIP-55, 0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed. Its lowercase form is 5aaeb6053f3e94c9b9a09f33669435e7ef1beaed, and keccak256 of that text begins d385650ce8fd. Comparing the first ten positions shows exactly where the capitals come from.

Position 1 is a and the hash character is 3, so it stays a. Position 2 is a and the hash character is 8, so it becomes A. Position 3 is e with hash character 5, so it stays lowercase. Position 9 is f with hash character 8, so it becomes F. Digits at positions 0 and 5-8 are copied unchanged. The result starts 5aAeb6053F, matching the published vector.


```sh
lowercase : 5 a a e b 6 0 5 3 f ...
keccak256 : d 3 8 5 6 5 0 c e 8 ...
rule      : - <8 >=8 <8 <8 - - - - >=8
checksum  : 5 a A e b 6 0 5 3 F ...

# ethers v6
import { getAddress } from "ethers";
getAddress("0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed");
// "0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed"
```


## What the checksum catches and what it does not

EIP-55 states that an address carries on average 15 check bits and that a randomly mistyped address has about a 0.0247% chance of still passing. That is roughly a 50-fold improvement over the earlier ICAP scheme, although the EIP notes it is weaker than a 4-byte check code. Wallets that validate checksums reject most single-character typos before a transaction is signed.

Two cases bypass the check. An all-lowercase or all-uppercase address carries no checksum at all, and most libraries accept it as valid input. More importantly, a checksum only proves the string was not corrupted; it says nothing about who controls the address. A look-alike address created by an attacker has its own perfectly valid checksum, which is why [address poisoning](https://www.ethvanity.com/blog/ethereum-address-poisoning) works even in checksum-aware wallets.


## How libraries and Solidity enforce the checksum

Most tooling validates EIP-55 automatically. In ethers v6, getAddress accepts an all-lowercase or all-uppercase address and returns the checksummed form, but throws an error if a mixed-case address has the wrong capitalization. viem behaves similarly: isAddress returns false for a mixed-case string with an invalid checksum under its default strict mode, and getAddress returns the checksummed form. Treat that error as a warning that the address was altered, not as a formatting nuisance to strip away.

The Solidity compiler applies the same rule to source code. Its documentation states that hexadecimal literals which pass the address checksum test are of address type, while hex literals between 39 and 41 digits long that fail the test produce a compile error. A vanity address pasted into a contract with its capitalization changed will therefore not compile until you use the correct EIP-55 form.

EIP-1191 later proposed a variant that mixes the chain ID into the hashed string, so the same address capitalizes differently per network. It was adopted by a few networks such as RSK, but Ethereum mainnet wallets and explorers use plain EIP-55. If a capitalization you see does not validate in standard tooling, check whether it was produced with a chain-specific scheme before assuming the address is wrong.

- Lowercase input: accepted by ethers, viem and Solidity tooling, returned in checksummed form.
- Correct mixed case: accepted unchanged.
- Incorrect mixed case: rejected, which usually signals a typo or a manual edit to the letters.

## Why case-sensitive vanity patterns multiply difficulty

A case-insensitive search for an n-character prefix needs 16^n attempts on average. If you also demand a specific capitalization in the EIP-55 form, each letter in the pattern adds a second condition: the corresponding hash nibble must fall in the upper half (8-f) for a capital or the lower half (0-7) for a lowercase letter. Each condition holds with probability 1/2, so each letter doubles the expected work. Digits add nothing because they have no case.

For example, 0xdead matched case-insensitively needs 16^4 = 65,536 attempts on average. Requiring exactly 0xDEAD needs 65,536 x 2^4 = 1,048,576 attempts. Requiring 0xC0FFEE needs 16^6 x 2^5 = 536,870,912 attempts, because only the five letters C, F, F, E and E carry a case constraint while the digit 0 does not.


| Pattern | Letters | Case-insensitive attempts | Exact-case attempts |
| --- | --- | --- | --- |
| 0xdead | 4 | 65,536 | 1,048,576 |
| 0x1234 | 0 | 65,536 | 65,536 |
| 0xc0ffee | 5 | 16,777,216 | 536,870,912 |
| 0xbadcafe | 7 | 268,435,456 | 34,359,738,368 |


## Checklist before you settle on a pattern

Treat the pattern, the matching mode and the final checksum as three separate decisions. A generator that reports a match on the lowercase value may hand you an address whose EIP-55 form shows unexpected capitals, so preview the checksummed output before committing to branding around it.

- Confirm every character is in 0-9 or a-f after any leetspeak substitution.
- Decide whether you care about capitalization; if not, match case-insensitively and save a factor of 2 per letter.
- Always publish the full 42-character checksummed address, never a shortened 0xabc...123 form, since short forms are exactly what look-alike attacks imitate.
- Remember a pattern is cosmetic: it does not prove ownership, and a readable name may suit you better, as compared in [vanity address vs ENS](https://www.ethvanity.com/blog/ethereum-vanity-address-vs-ens).

## Use the format rules in a real search

To apply these rules, follow the [Ethereum vanity address generator walkthrough](https://www.ethvanity.com/blog/how-to-generate-ethereum-vanity-address). Begin with a small fragment, specify its position and check the full output after generation. The examples on this page illustrate encoding; they are not addresses intended for deposits.


## Explore the related mechanism

- [Ethereum Vanity Address Difficulty: Attempts, Odds and Time](https://www.ethvanity.com/blog/ethereum-vanity-address-difficulty) — How hard is an Ethereum vanity address? 16^n expected attempts, EIP-55 case factors, prefix plus suffix, success odds and search time.
- [How Ethereum Addresses Are Derived from a Private Key](https://www.ethvanity.com/blog/how-ethereum-addresses-are-derived) — From secp256k1 private key to Keccak-256 hash, last 20 bytes and EIP-55 checksum, with an ethers v6 example and why it is one-way.
- [Open the complete workflow guide](https://www.ethvanity.com/guide) to place these checks in order.
- [Open the address generator](https://www.ethvanity.com/) when you have chosen a compatible format and pattern.

## Frequently asked questions

### Can an Ethereum vanity address contain the letters ETH?

No. Only 0-9 and a-f exist in hex, so t and h can never appear. You can approximate some words with substitutions such as 0 for o or 5 for s, but eth has no close hexadecimal spelling.

### Is an all-lowercase Ethereum address valid?

Yes. EIP-55 is an optional display encoding, so all-lowercase addresses are accepted by wallets and contracts. They simply carry no checksum, so a typo in a lowercase address is not detected.

### Does the checksum change the address?

No. The 20-byte value is identical whatever the capitalization. The checksum only changes how letters are displayed so that software can detect copying mistakes.

### How much harder is a case-sensitive vanity pattern?

Each letter in the pattern doubles the expected attempts, because the matching hash nibble must land in the required half. A 6-character pattern with 4 letters is 16 times harder in exact case. See the full math in [vanity address difficulty](https://www.ethvanity.com/blog/ethereum-vanity-address-difficulty).

### Why does my contract fail to compile with a vanity address literal?

Solidity requires address literals in valid EIP-55 form. Copy the checksummed address from a library such as ethers getAddress rather than retyping it with your own capitalization.

## Sources

- [EIP-55: Mixed-case checksum address encoding](https://eips.ethereum.org/EIPS/eip-55)

- [ethereum.org: Ethereum accounts](https://ethereum.org/en/developers/docs/accounts/)

- [ethers v6 documentation: getAddress](https://docs.ethers.org/v6/api/address/)

- [Solidity docs: address literals](https://docs.soliditylang.org/en/latest/types.html#address-literals)



Editorial method: https://www.ethvanity.com/about#publication-method