In 2021 we published a writeup on IDN homograph attacks and prevention, covering how Unicode lookalike characters let an attacker register a domain that is visually identical to a legitimate one. It remains one of our more-referenced posts, and the question we still get most often is a fair one: five years on, did the browsers fix it?

The short answer is that the address bar is largely handled, and everywhere else is not. The attack did not die. It moved.

What the browsers actually do now

Modern Chromium and Firefox both apply an IDN display policy before deciding whether to show a domain in Unicode or fall back to its Punycode form (the xn-- encoding). The logic draws on the Unicode security guidance in UTS #39, and in practice it comes down to a few checks:

• Mixed-script detection. A single label that mixes scripts in a suspicious way, for example Latin plus Cyrillic in one word, is shown as Punycode rather than the rendered glyphs.
• Whole-script confusables. Labels that are entirely made of characters confusable with another script get flagged.
• Locale and accept-language checks. Scripts that do not match what the user's browser is configured to read are treated with more suspicion.

The result is that the classic proof of concept, the all-Cyrillic string that renders as apple.com, now displays as xn--80ak6aa92e.com in an up-to-date desktop browser. The disguise breaks the moment the user looks at the address bar. That is real progress, and it is worth acknowledging.

Where it still works in 2026

The browser fix is narrow. It protects the address bar of an updated desktop browser, and almost nothing else. In our testing the attack surface that remains is large:

• Non-browser clients. Email clients, Slack, Teams, Discord, PDF viewers, IDEs, and terminal emulators frequently render Unicode link text without any Punycode fallback. The victim sees the lookalike, clicks, and only the browser they land in applies the policy, by which point the request is already made.
• Single-script targets. A label built entirely in one non-Latin script can slip past mixed-script heuristics, which matters when the target audience reads that script natively.
• ASCII homoglyphs. None of this touches plain-ASCII confusables like rn for m, l for I, or 0 for O. There is no Punycode involved, so there is no IDN policy to trigger.
• Display-name and path spoofing. The domain can be honest while the link text, the sender display name, or a lookalike subdomain does the deceiving.

What we tell people to rely on instead

Registry and registrar restrictions help. Many TLD operators now refuse mixed-script registrations or restrict a domain to a single script, which removes a slice of the problem at source. But relying on every registry worldwide to hold that line is not a defence you control.

The defence that actually works is to stop asking humans to authenticate URLs by eye. In order of effectiveness:

• Phishing-resistant authentication. FIDO2 and passkeys are bound to the real origin. A passkey registered for the genuine domain simply will not present on the lookalike, no matter how convincing it renders. This is the single control that makes the entire homograph payoff worthless, because the harvested credential no longer exists to harvest.
• Password managers. A manager that autofills based on the actual registrable domain will not offer credentials on the impostor. If it stays silent, that silence is a signal.
• Bookmarks over typed or clicked URLs for anything that matters, so the human is not in the URL-reading loop at all.

The RiotSec view

We treat IDN homographs in 2026 as a mostly-solved address-bar problem sitting on top of a completely unsolved everywhere-else problem. The Unicode lookalike space is permanent; you cannot patch human vision. So the useful engineering question is not "will the browser catch it," it is "does it matter if the user clicks." For any organisation still running password-based logins, the answer is that it matters a great deal, and the fix is not a better warning banner. It is passkeys, so that a convincing fake collects nothing worth having.

Our 2021 writeup still holds on the mechanics; treat this as the operational update. The characters have not changed. What has changed is that the defence finally has an answer that does not depend on anyone reading a URL correctly.