ENS normalization gives wallets, apps, and block explorers a shared way to interpret names. It protects users from less obvious risks involving Unicode, emoji, invisible characters, and look-alike scripts.
Type ENS.eth, Ens.eth, or ens.eth into a wallet with the latest ENS integration. Each version should lead to the same output: ens.eth.
This process is called normalization. It standardizes any ENS name input into a consistent format that ENS integrations should use before registration, resolution, or hashing.
The capitalized versions are acceptable inputs. They are not separate normalized ENS names that different people can register and use independently. Once processed according to the ENS normalization standard, they all refer to ens.eth, a fully lowercase output.
Capitalization, however, is the easy part.
ENS is a global naming system. Names should be useful even when written in different languages, scripts, and emojis rather than being limited to the English alphabet.
That flexibility comes from Unicode, the standard modern software uses to represent text. It also creates situations where two names can look identical on screen while containing different underlying characters.
The Latin a and Cyrillic а, for example, can appear nearly identical in some fonts. To a person, they may look like the same letter. To a computer, they are entirely different characters.
Other Unicode characters can be invisible, combine with nearby letters, or change how text is displayed. A single emoji may actually contain several characters joined together, and the same sequence may render differently across devices.
A lowercase-only solution might handle ENS.eth, but it won't reliably catch look-alike scripts, invisible characters, combining marks, or complex emoji sequences.
ENSIP-15 defines the normalization standard used across ENS integrations. Finalized in 2023, it gives wallets, apps, libraries, and block explorers a common set of rules for interpreting names.
The process works label by label. In subdomain.ens.eth, for example, subdomain, ens, and eth are separate labels.
Each label is converted into a consistent Unicode form and checked against rules covering valid characters, character placement, writing-system compatibility, visually confusable scripts, and supported emoji sequences.
The outcome is deliberately straightforward: the process either returns one normalized name or rejects the input because it cannot be safely normalized.
Normalization cannot remove every possible visual ambiguity. Fonts, devices, and human perception will always vary. But it gives ENS integrations a consistent and much safer baseline.
ENS contracts generally work with hashes rather than readable strings. The namehash algorithm converts a name into a fixed-length identifier that contracts can use.
The safe order is:
User input → normalization → namehash → ENS contracts
The process begins with the name exactly as a user enters it. An ENS-compatible app first normalizes that input according to ENSIP-15, converting valid variations into one standard form and rejecting anything that cannot be interpreted safely.
The normalized name is then passed through namehash, which turns it into the fixed-length identifier used by ENS contracts. Those contracts use the resulting hash to look up the name's owner, resolver, records, and other onchain data.
Even a tiny difference in the original input can produce a different hash, which is why normalization needs to happen first. If a name cannot be normalized, an integration should reject it rather than hash or resolve the raw input.
Normalization helps determine which name an app is resolving. Verification determines whether that name should be displayed for a particular address.
A primary name enables apps to show an ENS name in place of an address. The process begins with an address claiming a name through reverse resolution, but that claim alone isn't enough.
Before displaying a primary name, an app verifies that the claimed name is valid and normalized, then performs forward resolution to confirm that it points back to the same address.
An unnormalized claim is not rewritten and verified as a different name. The claimed name itself must pass normalization.
If normalization or forward verification fails, the address is displayed instead. This prevents an arbitrary name claim from being presented as a verified ENS identity.
Developers don't need to recreate ENSIP-15 themselves. Maintained libraries already implement the standard and evolve alongside Unicode.
The reference JavaScript package implements ENSIP-15 directly. ENSjs and viem also provide ENS-aware name handling.
The main principles are simple: use an established ENS normalization library, reject input that cannot be normalized, and verify primary names before displaying them.
Integrators should pass the original user input into the library rather than first lowercasing it, stripping unfamiliar characters, or applying custom Unicode logic. Those shortcuts can produce results that differ across applications.
More implementation guidance is available in the ENS name-processing documentation. The ENS team is also happy to help developers confirm that normalization, resolution, and primary-name display are working as intended.
When normalization works properly, the experience is smooth. Someone types a name, and every up-to-date app agrees on what that name means.
Human-readable names work best when the ecosystem interprets them consistently. Normalization provides the shared foundation that allows people to rely on ENS more intuitively.