Convert internationalized domain names between Unicode (bücher.de) and their xn-- ASCII form (xn--bcher-kva.de) — per label, in both directions. The homograph visualizer below the converter breaks a domain into characters and flags mixed scripts and lookalike letters, the raw material of phishing domains.
DNS only speaks ASCII, so Unicode domains are encoded: bücher.de → xn--bcher-kva.de The xn-- prefix marks an encoded label; the tail after the last hyphen tells the decoder which non-ASCII characters to insert, and where. Your browser does this silently on every IDN you visit.
Homograph check
Conversion runs entirely in your browser — domains you check are never sent anywhere, and the page works offline once loaded. The homograph check flags visual risk signals; it is not a verdict on whether a site is legitimate.
[ Ad slot — replace with AdSense / Ezoic code ]
What internationalized domain names are
The domain name system predates Unicode: hostnames were defined as letters a–z, digits, and hyphens, and every resolver, registry, and cache on the internet assumes that alphabet. Rather than upgrade all of it, internationalized domain names (IDN) work by encoding: the Unicode name users see is mechanically transformed into an ASCII-compatible form that starts with xn--, and that is what's actually registered and resolved. Your browser converts in both directions automatically — type münchen.de and it queries DNS for xn--mnchen-3ya.de; land on an xn-- URL and it may display the Unicode form (or deliberately not — see the phishing section).
The encoding applies per label — each dot-separated segment independently. A label that's already pure ASCII is left untouched, which is why bücher.de becomes xn--bcher-kva.de: only the first label needed encoding.
How the xn-- encoding works
The algorithm is Punycode (RFC 3492), and it's cleverer than an escape syntax. It splits a label into its ASCII characters, which are copied through literally, and its non-ASCII characters, which are described compactly at the end:
bücher
ASCII part: b c h e r → "bcher"
non-ASCII part: ü (U+00FC), to be inserted at position 1
encoded tail: "kva" (encodes: which char + where)
label: bcher + "-" + kva
with prefix: xn--bcher-kva
The tail is a variable-length integer code (in a 36-character alphabet, a–z plus 0–9) that enumerates each non-ASCII character as a pair of "what code point" and "what position", ordered so that the decoder can replay the insertions. Repeated or nearby characters cost very few extra letters, which keeps encoded labels short even for names entirely in Arabic or Chinese — important, since encoded labels still must fit DNS's 63-byte label limit. A label with no ASCII characters at all is just the prefix, a hyphen delimiter omitted, and the tail: 💩 encodes to xn--ls8h.
Alongside Punycode itself, the IDNA rules handle practical matters: labels are case-folded (domains are case-insensitive), and several Unicode dot lookalikes (。 ． ｡) are treated as label separators — this converter does both.
Homograph attacks: why lookalike letters matter
Unicode contains many characters that are visually identical to Latin letters but are, to a computer, entirely different characters. Cyrillic а (U+0430) and Latin a (U+0061) render indistinguishably in most fonts — which means pаypal.com with a Cyrillic а is a different domain from the real one, separately registerable, with its own DNS records and its own TLS certificate. That's a homograph attack, and it's why the converter above pairs every conversion with a character-level breakdown.
The visualizer flags the two strongest risk signals. Mixed scripts in one label: legitimate names are almost always written in a single script, while lookalike attacks typically swap one or two characters, leaving a Latin word with a Cyrillic intruder. Known confusables: characters from the Unicode confusables list that imitate Latin letters (Cyrillic а е о р с у х ѕ і ј һ, Greek ο ν, and others) are called out individually with what they imitate. Browsers apply similar heuristics when deciding whether to display Unicode or the raw xn-- form in the address bar — showing the punycode is the browser telling you it doesn't trust the name's appearance. A practical habit: when a link's domain matters (banking, package delivery, account resets), paste it here or read the xn-- form; ASCII can't lie about what it is.
Why do encoded domains start with xn-- specifically?
DNS needed an unambiguous marker meaning "this label is encoded Unicode, not a literal name" that was also a valid hostname string and vanishingly unlikely to collide with real names. The IDNA standard reserved the four-character ACE (ASCII-Compatible Encoding) prefix xn-- for that job — two letters chosen precisely because no meaningful names started with them, followed by the double hyphen that ordinary registrations avoid in positions three and four. A resolver that doesn't understand IDN just treats it as an ordinary odd-looking label, which is the point: the whole scheme deploys without touching DNS itself.
Are emoji domains real?
Technically yes — Punycode encodes any code point, so 💩 becomes xn--ls8h and a registry that permits it can sell it. In practice, IDNA 2008 disallows emoji, so most TLDs reject them; a handful (famously .ws, .la, .to, .fm) permit them as a novelty. They're a poor foundation for anything serious: browsers typically display the raw xn-- form, many apps can't parse them in links, email support is erratic, and emoji render differently on every platform. Fun to own, risky to build on.
Why does my browser show xn--… instead of the Unicode name?
It's a deliberate anti-spoofing decision. Browsers display the Unicode form only when the name passes their safety heuristics — single script (or an allowed combination), no confusable mixing with a known name, sometimes per-TLD policy. Fail a check and the address bar shows punycode so a fake can't visually impersonate a real domain. If a link you trusted displays as xn--, treat that as the browser raising an eyebrow: decode it here and look at the character breakdown before entering credentials.
Is this the same encoding browsers use?
The Punycode transformation is the same RFC 3492 algorithm, verified against the RFC's own test vectors, plus per-label handling, case folding, and Unicode dot separators. Full IDNA additionally applies per-character eligibility rules (which characters may appear in registered names at all, contextual rules for joiners, bidi constraints); this tool doesn't reject names on those grounds, so it will happily convert strings a registry would refuse — useful for analysis, but registration is the registry's call.
Does the homograph check prove a domain is safe or fake?
Neither. A clean single-script result doesn't make a site legitimate (plain-ASCII phishing domains exist in vast numbers), and a mixed-script flag isn't proof of fraud — some legitimate names genuinely mix scripts. The check surfaces the specific deception technique that's invisible to the naked eye; the verdict about trusting a site still involves the usual signals: how you got the link, the certificate, and whether the organization actually uses that domain.