IDN Homograph Detector

About IDN Homograph Detector

An IDN homograph attack registers a name that reads as a familiar one but is not it. аpple.com with a Cyrillic а is a different domain from apple.com, resolves somewhere else, and can hold a valid certificate for itself — nothing in the glyphs says which one you are looking at. This checks a name for the three things such an attack needs and an honest name rarely has.

The strongest signal is two scripts inside one label: аpple is part Cyrillic and part Latin, where münchen, 日本語 and example are each written in one script throughout. That test does not depend on any list being complete, which is why it is the one browsers use to decide whether to show you a name or its punycode. Alongside it the tool names the individual characters chosen to be read as ASCII, and the characters that are not drawn at all — a zero-width joiner changes a name without changing the picture.

Where it helps

• Mixed scripts inside a label are caught by rule rather than by list, so a novel character combination is still found.
• Punycode input is decoded first, which is the form one of these is usually met in.
• Names the specific characters and their code points, so a finding can be checked rather than taken on trust.
• Says what the name reads as, which is the name it may be impersonating.

Limits

• A clean result is not proof of safety. A name written entirely in one non-Latin script that happens to read as an English word trips no mixed-script rule, and only the curated lookalike list can catch it.
• That list is the characters these attacks actually use, not all of Unicode's confusables, which run to tens of thousands of pairs and change between versions.
• It judges the characters, not the registration. A name can be entirely above board and still belong to somebody you would rather not send a password to.
• It does not resolve anything or look at a certificate, so it cannot tell you where the name points.

Frequently asked questions

My browser shows xn-- instead of the name. Why?

Because it applied roughly this test and decided the readable form could not be shown safely. Seeing the punycode form in the address bar is the browser telling you it did not trust the display.

Is a non-ASCII domain a bad sign on its own?

No. Most of the world's languages need one, and a name written consistently in a single script is ordinary. What is suspicious is a name that borrows characters from a second script to look like something it is not.

It found nothing. Is the name safe?

It means nothing was found, which is not the same thing. Check where the name actually points and who holds its certificate before trusting it with anything.

What is the reads-as line?

The name with every lookalike character replaced by the character it imitates. If that line is a well-known domain and the name above it is not, that is the whole of the attack.

Related tools

• Punycode — Convert internationalised domain names to and from their ASCII form
• Unicode Converter — Escape, unescape and inspect code points
• SSL Checker — Grade a TLS endpoint and inspect the certificate it serves
• DNS Lookup — Resolve A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records
• Log Analyzer — Summarise a log: rates, errors, slowest paths and busiest clients
• HAR Analyzer — A network recording as a waterfall: what was slow, heavy, uncached or failing

More Analyzers tools

• Log Analyzer — Summarise a log: rates, errors, slowest paths and busiest clients
• HAR Analyzer — A network recording as a waterfall: what was slow, heavy, uncached or failing
• Phishing URL Checker — Where a link really ends up, how old the domain is, and which tricks it uses
• Injection Filter Tester — Standard probes per context, and whether your escaping survived them
• Stack Trace Analyzer — Read a stack trace or crash in any common language: the cause, your frames, and what it usually means