Unicode Homoglyphs in Domains: Inspect the Hostname, Not the Logo

Two domain names can look almost identical while containing different characters. A Latin letter and a character from another script may share a similar shape in a font. That creates an identity problem: a familiar-looking word doesn't necessarily identify the familiar organisation.

Unicode homoglyph review is about understanding the actual string and ownership, not declaring every internationalised domain suspicious. Many legitimate languages need non-ASCII characters. The useful defence combines careful representation with independent verification of the request.

Inspect the hostname itself

Read the parsed hostname rather than a logo, page title, or brand name in the path. A service can display familiar branding without owning the expected domain. A long URL can also place a convincing name somewhere other than the host.

The MDN URL interface reference explains reading parsed components such as hostname and origin. Use those explicit components in application checks, then apply an ownership or allowlist policy separately. A parser can describe a URL without endorsing its destination.

Use reserved example domains for training. In a synthetic string such as pаypal.example, the second character can be Cyrillic а rather than Latin a. The .example suffix here marks an illustration, not a site to visit.

Don't rely on visual inspection alone, especially on a small screen or in a font where characters resemble each other. Reveal the string's underlying representation using an approved local workflow and verify the expected domain independently.

Distinguish encoding from identity

Internationalised domain processing can represent a hostname differently for network use. A browser may display Unicode or an ASCII-compatible representation according to its own rules. Percent encoding elsewhere in a URL is another mechanism with a different purpose.

The Unicode security mechanisms standard describes confusable-character analysis and related considerations. It is not a universal “safe domain” list. A confusable result indicates a comparison worth reviewing, not proof that the owner is malicious.

For a synthetic percent-encoded component, URL Decoder can reveal decoded text. It doesn't perform IDN ownership verification or a complete confusable analysis. Don't assume decoding a URL makes its destination trustworthy.

Compare code points when the string matters

In an authorised local test, inspect the code points rather than only the rendered text. A small JavaScript example can make the distinction visible:

const sample = "pаypal.example";
const points = Array.from(sample, ch =>
  `U+${ch.codePointAt(0).toString(16).toUpperCase()}`
);
console.log(points);

The sample is deliberately synthetic. It illustrates inspection, not a production phishing detector. Grapheme clusters, combining marks, and domain-processing rules can require more specialised handling than this short example provides.

Use JavaScript Formatter to review synthetic inspection code. It formats source; it doesn't execute it or determine whether a domain is safe. Run any diagnostic only in an environment you control.

Don't assume normalisation removes lookalikes

Unicode normalisation can make some equivalent representations consistent. It doesn't simply convert every visually similar character to a Latin letter. A normalised string can still contain characters that resemble another name.

For identifiers in your own application, define a policy appropriate to the audience. Consider allowed scripts, mixed-script review, and confusable comparisons where the identity risk warrants them. Avoid blanket rules that unnecessarily exclude legitimate names.

Keep display names separate from immutable account identifiers. A familiar-looking display name should not become the sole basis for granting access, selecting a recipient, or approving a payment. The underlying verified identity matters more than typography.

Verify the request through an independent route

If a message asks for a password, payment, or software installation, open the known official app or site yourself. Use a previously trusted contact method to confirm unexpected changes. Don't keep inspecting a questionable page while already signed in with sensitive accounts.

HTTPS confirms aspects of the connection to the domain presented; it doesn't establish that a lookalike domain belongs to the organisation you intended. A padlock and polished design are not substitutes for checking identity.

For a benign public URL you own, Redirect Checker can show ordinary hops. It isn't a phishing verdict or an IDN analyser. Do not submit active malicious links, private URLs, or addresses containing access tokens.

Test your application's identity displays

Use synthetic names containing mixed scripts and visually similar characters. Check search results, account lists, notifications, and administrative approvals. Make sure critical interfaces expose enough verified information to distinguish accounts safely.

Review copy-and-paste behaviour as well. A string may look one way in the UI and another in a log or export. Preserve the original value where needed for evidence, alongside an explicit safe representation for review.

Apply these checks to domain allowlists and callback validation too. Use a maintained parser and the provider's supported identity rules. Substring matching a brand name isn't a reliable access-control decision.

Give reviewers a way to copy the full identifier and compare it with the approved record. Hiding the hostname behind a friendly label may improve appearance while removing the information needed for a sensitive decision. Reserve that convenience for contexts where identity has already been established.

If your application fetches links on the user's behalf, read server-side URL fetcher defence. Human recognition and server destination policy are separate boundaries. A URL that looks plausible to a person must still pass the application's network restrictions.

Conclusion

Visual similarity is a prompt to inspect, not proof of ownership. Check the actual hostname, understand its representation, and verify sensitive requests independently. Support legitimate Unicode while keeping critical identity decisions tied to verified identifiers rather than familiar-looking text.