Read lookalike names without inventing a verdict

Guide Last tested 25 October 2026

A lookalike address can use similar-looking characters, a misleading subdomain or text before an @ sign to disguise its actual hostname. Read the parsed hostname and its ASCII form, then compare the registrable boundary with the address you intended to use. Neither a normal-looking name nor a punycode prefix tells you whether its operator is trustworthy.

Separate the hostname from everything around it

Start with reading a URL hostname, because a convincing label elsewhere in an address is not the destination. In https://sample.test.account.invalid/signin, the hostname is sample.test.account.invalid. The familiar-looking sample.test text sits to the left of another name. It does not make this a page under sample.test.

The path can create the same distraction. In https://account.invalid/sample.test/signin, the text after the first slash is a path. A copied sentence that displays “sample.test” as link text can obscure the actual address even more. For inspection, work with the address string itself in a trusted local context; the spelling of the visible sentence is a separate piece of evidence.

An authority can also contain user information. In https://sample.test@signin.example.test/, the hostname is signin.example.test; the text before @ is not the host. The URL parser reference shows why a parser’s fields are more useful than searching a string for an expected word. This example is inert and uses reserved names; it is not a destination to visit.

The registrable-boundary guide explains the next step. A public-suffix rule helps separate the suffix from a registrable part, including private and exception rules. That is a naming boundary, not proof that a registration exists or that one company controls every related service. Keep those questions separate in an investigation note.

What the two Unicode standards do

Unicode Technical Standard 46 describes compatibility processing for internationalized names, including conversion between Unicode and ASCII representations. The current document read for this page is version 18.0.0, revision 36, dated 31 August 2026. It addresses processing and validity, rather than deciding whether a particular operator is honest¹.

Unicode Technical Standard 39 addresses security mechanisms for identifiers, including confusable strings and script restrictions. The current document is version 18.0.0, revision 34, dated 27 August 2026. It offers ways to identify potential ambiguity; a result depends on the selected checks and comparison strings². A system can accept an internationalized name while still finding it visually confusable with another name.

Punycode is not encryption and does not hide a secret owner behind an address. It encodes a non-ASCII label in an ASCII-compatible form, commonly recognizable by the xn-- prefix. Legitimate names in many writing systems need this representation. A rule that treats every internationalized name as malicious would confuse writing-system support with evidence about behavior.

There is also no single “looks the same” test. A font, size and reader’s familiarity can affect visual recognition. A machine comparison uses defined mappings and restrictions. Record which kind of evidence you have: the exact characters, a code-point sequence, a confusable comparison, a display observation, or a provider’s reputation result. Do not let one stand in for all the others.

Six reserved examples through a pinned checker

The reproduction files run ICU 78.1’s spoof checker and UTS 46 conversion on six reserved names. The checker uses its default check set; conversion uses the recorded nontransitional options. ICU 78.1 and its bundled Unicode 17.0 data are pinned for reproduction. This older implementation predates ICU 78.3, released 17 March 2026, and ICU 79.1, released 22 October 2026; the latter updates to Unicode 18³. Reading the current version-18 standards does not turn the pinned 78.1 run into a version-18 conformance test.

The first pair differs in one character. sample.test contains Latin a, U+0061. sаmple.test uses Cyrillic а, U+0430, in that position. The letters can resemble one another in ordinary text even though they are different characters. ICU’s comparison marked that pair confusable and its configured restriction check returned a nonzero result for the mixed-script example.

The second comparison uses scope.test and ѕсоре.test. The non-ASCII label uses Cyrillic characters. The full input also contains the Latin .test suffix, so the recorded whole-string check includes that mixture. The article does not relabel the output as a browser’s decision about one individual label; those are different procedures.

Every conversion completed without an IDNA error. That means these inputs passed this conversion configuration, not that the names are registered. The result for bücher.test is especially useful: an accented name produces punycode without matching the particular comparison name. A comparison against one reference cannot rule out similarity to every possible name.

ICU’s comparison also returns a confusable category for identical strings. That is expected from a string-comparison API, not a warning that the reference itself is an attack. The recorded output preserves numeric flags, comparison names and options so readers can distinguish that baseline from the two non-identical examples. The library’s own API documentation explains the result categories⁴.

Why the address bar may show something different

Browsers apply their own display policies after processing a name. Chromium’s documented policy considers labels, script combinations, disallowed characters, unusual patterns and other checks before choosing Unicode or ASCII display. It also documents protections for lookalike names beyond basic conversion⁵. An ASCII result in this table therefore does not predict exactly how a browser will display that name.

Do not infer a browser result from a screenshot of another product or version. If a future investigation needs display evidence, record the browser version, exact input and displayed text without turning that observation into a universal rule. This page has no new browser-navigation observations. The pinned character checker supplies a smaller, reproducible fact that does not require visiting any example.

Conversely, readable Unicode is not an endorsement. A browser may allow a name to remain readable because it meets the product’s display policy. That policy addresses presentation risks, not all possible fraud, compromised content or misleading business claims. An ASCII-only address can be deceptive too, without triggering a Unicode-specific mechanism.

Use the result to decide what to verify next

For an unexpected message, compare its claimed organization with an address you obtained independently through an established channel. You do not need to visit the disputed link to identify a mismatch in the text. If you already have a trusted bookmark or a known application, use that independently instead of modifying the suspect address until it looks plausible.

The passive inspector is useful when the immediate question is which host and boundary the supplied text contains. It does not resolve the name, retrieve its content or test a certificate. The HTTPS explainer covers why an encrypted connection would answer a different question. The reputation limits guide explains why even a provider’s no-match result is narrower than a safety guarantee.

If you document a confusing name, retain the exact code points in private evidence and use a reserved, clearly labelled example when explaining the pattern publicly. Record the comparison target and the tool’s options. A label such as “mixed-script comparison to sample.test” is more precise than “fake domain detected,” because it states what was actually established and leaves ownership and intent unresolved.

For an owner investigating their own naming or support materials, consistency helps: use a known hostname in official communications and explain legitimate internationalized spellings. Do not promise that one spelling will always be displayed identically by every client. If a browser presents a deceptive-site warning, use the owner warning guide rather than treating a character comparison as grounds to dismiss it.

Not covered on this page

• Ownership, registration availability or trademark conclusions.
• A browser-by-browser display test or visual perception study.
• Reputation lookups, destination retrieval or warning bypasses.
• Exhaustive confusable comparisons or Unicode 18 implementation conformance.