DevKitHub

Encoding & Conversion

Punycode Converter and IDN Homograph Checker

Convert a domain between Unicode and its xn-- form, and see whether it contains characters chosen to make it look like a different domain.

Single script

Both forms

Unicode
münchen.example.com
ASCIIwhat DNS sees
xn--mnchen-3ya.example.com

This tool runs entirely in your browser. Your input is never uploaded, stored or logged.

How it works

The mechanical half is the RFC 3492 bootstring algorithm, which converts a Unicode label to the xn-- form that appears in DNS, in certificates and in logs, and back again. That form is unreadable by design, so having it converted matters whenever an internationalised domain shows up somewhere that does not render it.

The half worth having is the homograph check. Cyrillic "а" at U+0430 and Latin "a" at U+0061 render identically in nearly every font, so a domain spelled with the Cyrillic letter looks exactly like the real one and is not. Browsers defend against this by showing the punycode instead — but the rules differ between them and depend on the script involved. Anywhere outside a browser address bar there is no defence at all: an email client, a terminal, a chat window, a log viewer will all render the lookalike happily.

So each label is checked for two things. Mixing scripts inside a single label is flagged, because legitimate domains essentially never do it and it is the signature of a name built to impersonate another. Individual characters that render as ASCII but are not — the Cyrillic and Greek lookalikes, and the several Unicode characters that render as a full stop — are named with their code points and what they resemble. The punycode form is shown alongside, because that is the representation in which the two names are obviously different.

Common problems

Every example below is run against this tool in our test suite, so what it says here is what the tool actually does.

That begins with xn-- but is not valid punycode.

xn--!!!.com
Why:
The xn-- prefix marks an encoded label, and the body after it must be valid bootstring. A truncated or hand-edited label fails here rather than decoding to something misleading.
Fix:
Re-copy the label. Punycode bodies use only letters, digits and hyphens.

Two domains look identical but behave differently.

Why:
One contains a lookalike character — most often Cyrillic а, е, о, р or с standing in for the Latin letter. The rendered names are indistinguishable; the punycode forms are not.
Fix:
Compare the xn-- forms rather than what is displayed. This tool shows both, and flags the characters involved.

A link in an email went somewhere unexpected.

Why:
Browsers show punycode for suspicious names, but mail clients, terminals and chat apps generally do not. The protection people assume is universal belongs to the address bar alone.
Fix:
Paste the domain here before trusting it. A mixed-script label is close to conclusive.

Frequently asked questions

What is a homograph attack?
Registering a domain that renders identically to another by substituting lookalike characters from a different script — Cyrillic а for Latin a, for instance. The names are visually indistinguishable and technically unrelated.
Do browsers not protect against this already?
Partly, and inconsistently. They show punycode for names they consider suspicious, but the rules differ by browser and script, and nothing outside the address bar applies them — mail clients, terminals and chat apps render the lookalike as-is.
Why flag mixed scripts rather than specific characters?
Both are flagged, but mixing scripts inside one label is the stronger signal: a legitimate domain is written in one script, and a name that combines two is almost always built to impersonate something.

Last updated