How Ethereum Addresses Work: Format, Checksum, Safety

Every Ethereum transaction, token transfer and smart contract call points at a short string that starts with 0x. It looks random, yet it is the end of a precise chain of cryptography — and one wrong character can send funds somewhere nobody can ever reach. If you build wallets, dApps or payment forms, understanding how these addresses are made, displayed and validated will save you bugs and save your users money.

From private key to address

A normal (externally owned) Ethereum account starts with a private key: a 256-bit secret number. From it, elliptic-curve math on the secp256k1 curve produces a public key. The address is then derived in three steps:

1. Take the 64-byte uncompressed public key.
2. Hash it with Keccak-256, which gives 32 bytes.
3. Keep only the last 20 bytes and write them as 40 hexadecimal characters with a 0x prefix.

Because hashing only works one way, nobody can work backwards from an address to the key. That is also why an address made up at random has no owner: there is no known key that hashes to it.

Contract addresses and special addresses

Smart contracts have addresses in the same 20-byte format, but they are not derived from a key. With the classic CREATE opcode, the address comes from the deployer’s address and its transaction count (nonce); with CREATE2, it comes from the deployer, a chosen salt and the contract code, so it can be predicted before deployment.

A few addresses have conventional meanings you will meet in test data and logs:

• The zero address (0x plus forty zeros) appears as the sender when tokens are minted and the recipient when they are burned in many token contracts.
• “Dead” addresses ending in patterns like dEaD are popular burn destinations because nobody is expected to hold their key.

The EIP-55 checksum: why some addresses have capitals

Hex is case-insensitive, so 0xAB and 0xab are the same value. EIP-55 uses that freedom to hide a checksum in the letters. The lowercase address is hashed with Keccak-256, and each letter a–f in the address is capitalized if the matching character of the hash is 8 or higher.

The result is a mixed-case address that wallets can verify: change one character and the capitalization pattern almost certainly stops matching. Practical rules for your code:

• All-lowercase or all-uppercase addresses carry no checksum and are accepted as plain hex.
• Mixed-case input should be validated against EIP-55 and rejected if the pattern is wrong.
• Store addresses in one canonical form (usually lowercase) and compare them case-insensitively.

How to generate test addresses with RandNow

For interface and validation testing you rarely need a real account — you need many well-formed strings. The Random Ethereum Address Generator handles that in your browser:

1. Open the tool and choose how many addresses you want, up to 100 per batch.
2. Click generate. Each result is 0x followed by 40 lowercase hex characters, created with the Web Crypto API.
3. Copy the list or export it as CSV, JSON or TXT for fixtures, seed files or spreadsheets.
4. If you need checksummed versions, pass the addresses through the EIP-55 function in your own library and use both forms to test case handling.

Remember that these addresses are not backed by a private key. Treat them strictly as placeholders and never send real funds to them.

A test checklist for address inputs

Use a batch of generated addresses, plus a few hand-edited bad ones, to cover the cases real users hit:

• Length: reject 39 or 41 hex characters and a missing 0x.
• Characters: reject g–z, spaces in the middle and smart quotes pasted from documents.
• Whitespace: trim leading and trailing spaces and line breaks before validating.
• Checksum: flip the case of one letter in a valid mixed-case address and confirm the warning appears.
• Display: check that long addresses truncate gracefully, such as 0x1234…abcd, and that the copy button copies the full value.

Pro tips

• Use a public testnet with real key pairs whenever you need to send transactions; use random addresses only for UI and validation tests.
• Show the first and last few characters prominently so users can compare addresses at a glance.
• Never auto-correct an address that fails its checksum — ask the user to check it.
• Keep a fixed set of exported addresses in your repository so tests stay reproducible.

Frequently asked questions