Skip to content
AdminKit
Live Updated

IDN homograph check: is this domain a lookalike?

How does this check work, and what does the result tell you?

AdminKit's IDN homograph check reads a domain name or URL entirely in your browser and shows both its Punycode (xn--) form and its Unicode form, side by side, then flags labels that mix scripts, carry non-ASCII characters, or use a character from a curated confusables list — the techniques behind IDN homograph and lookalike-domain phishing.

Part of the DNS cluster — more tools, guides and terms on dns.

Checked entirely in your browser — nothing you type is sent to AdminKit or anywhere else, and this tool never queries DNS or any server.

What the result means

"Flagged" means the domain's labels contain non-ASCII characters, mix more than one script (for example Latin and Cyrillic in the same label), or include a character from AdminKit's curated confusables list — any of which is how a lookalike domain is built. It does not mean the domain is malicious: some flagged domains are entirely legitimate, non-English registrations. "No flags found" means none of those heuristics triggered for the labels checked — it does not mean the domain is safe, only that this particular check found nothing.

Next step

A lookalike domain can still have working DNS and even a valid TLS certificate, so character-level flags are only one signal. Use AdminKit's DNS lookup and WHOIS to see what the domain actually resolves to and who it is registered to, and SSL/TLS check to see its certificate — a certificate only proves the connection is encrypted, not that the site is who it claims to be.

Keep this result

Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.

How it works and limits

Paste a domain name or a full URL. The tool extracts the hostname, splits it into its DNS labels, and for each one shows the Punycode (xn--) form the DNS wire protocol actually uses and the Unicode form a person reads — then flags non-ASCII characters, labels that mix more than one script, and characters from a small curated confusables list. Nothing you type is sent anywhere; the sections below explain the Punycode codec and the risk heuristics in detail.

How does Punycode represent a Unicode domain name?

RFC 3492 defines Punycode, a reversible ASCII-only encoding for the Unicode code points a DNS label can’t carry directly. RFC 5891 (IDNA2008) is what tells a resolver to apply it: an “internationalized” label is encoded to xn-- plus its Punycode form before it ever reaches a nameserver, and decoded back to Unicode for display by a browser or this tool. The two forms are the same label; this page shows both so you can see exactly what a browser’s address bar is hiding or revealing.

Why would a single-script, non-ASCII domain still be worth checking?

It usually isn’t a risk by itself — a domain entirely in German, Vietnamese, Cyrillic, Greek or Han script is a normal, legitimate registration, and this tool says so. The risk is specifically a label that mixes scripts (Latin characters next to Cyrillic or Greek ones) or that substitutes a character from the curated confusables list below, because that is how a lookalike domain is deliberately built to pass a glance. Unicode Technical Standard #39 catalogues the full “confusables” problem; this tool implements a small, hand-picked subset of it (common Cyrillic/Greek look-alikes of Latin letters, plus the classic digit-for-letter swap) rather than the complete table.

Limits

  • This is a heuristic phishing-awareness aid, not an authority: the curated confusable-character list is small and deliberately not exhaustive, and new lookalike tricks appear over time.
  • A flagged domain is not proof of malice — plenty of legitimate, non-English domains will be flagged for containing non-ASCII characters, because they genuinely do.
  • A clean result (“no flags found”) is not proof of safety — it only means this specific check found nothing; it is not a verdict on the domain’s reputation, ownership or intent.
  • This tool never queries DNS, WHOIS or any server, so it cannot tell you whether the domain is even registered, who registered it, or what it resolves to — always verify the real registered domain before trusting a link, using AdminKit’s DNS lookup and WHOIS.

To see where a suspicious link in an email actually routes before you click it, paste its headers into AdminKit’s email header analyzer, and for the DNS records a domain actually publishes, see how to read a DNS lookup result.

Frequently asked questions

Does this tool look up DNS or send the domain I type anywhere?

No. Everything runs in JavaScript in your browser tab: converting between Punycode and Unicode, and checking each label's characters. The page makes no network request with what you type, and it never queries DNS, WHOIS or any server — closing the tab discards it.

If a domain is flagged, does that mean it's a phishing site?

No — a flag means a label contains non-ASCII characters, mixes scripts, or includes a curated confusable character, which is how homograph domains are built, but plenty of flagged domains are entirely legitimate, non-English registrations (a city's own name, a local business, a brand in its home script). Treat a flag as "look closer," not as a verdict, and check who actually registered the domain with AdminKit's WHOIS before deciding anything.

Why does a legitimate domain like münchen.de get flagged as containing non-ASCII characters?

Because it genuinely does — "ü" is outside the ASCII range, so IDNA (RFC 5891) encodes the label as Punycode (xn--mnchen-3ya) for the DNS wire format. This tool flags every non-ASCII character so you can see it, but "non-ASCII" on its own is not a danger signal; the mixed-script and confusable-character flags are the ones built specifically to catch spoofing, and a single consistent script (German, Vietnamese, Cyrillic, Greek, Han, and so on) is normal, legitimate IDN use.

What's the difference between an IDN homograph attack and ordinary typosquatting?

Typosquatting relies on a misread or mistyped sequence of ordinary ASCII characters (paypa1.com, gooogle.com); an IDN homograph attack swaps in a character from a different script — most often Cyrillic or Greek — that renders identically or near-identically to the Latin character it replaces, so the domain can look completely correct even on close reading. Unicode Technical Standard #39 ("confusables") catalogues the character pairs this trick depends on.