Domain names are technically restricted to ASCII, so internationalized domain names — anything using non-Latin scripts, accented characters, or Latin variants with diacritics — are transmitted using punycode, an encoding that represents Unicode text as an ASCII string prefixed with xn--. Browsers decode this transparently and display the actual Unicode characters in the address bar, which is convenient for legitimate internationalized sites and is exactly the mechanism homograph phishing attacks exploit: the decoded Unicode text can be a near-perfect visual match for a well-known brand's domain, using letters that are structurally different code points.
Punycode's encoding is genuinely clever — it separates a domain label's basic ASCII characters from its non-ASCII characters, encodes the non-ASCII ones' positions and code points using a variable-length integer scheme, and appends the result after the ASCII portion and a delimiter. Decoding it requires implementing that same variable-length scheme in reverse; it's not a simple substitution cipher, which is part of why most people can't eyeball an xn-- string and know what it represents.
The security-relevant question is never 'is this domain internationalized' — plenty of legitimate businesses have real non-English domains — but 'do the decoded characters visually resemble a different, well-known domain using different code points.' аpple.com with a Cyrillic 'а' decodes to a string that looks like 'apple.com' in most fonts but isn't the same bytes at all, and only decoding the punycode and then running the result through a confusables check reveals that mismatch.
This decoder converts any xn-- labeled domain back to its Unicode form, then cross-references every character against a confusables table to flag characters that are visually near-identical to more common Latin letters — surfacing exactly the pattern used in the large majority of homograph domain attacks.
Edge cases worth knowing
- A legitimate internationalized domain with no confusable characters
- münchen.de-style domains decode to real, unremarkable non-English text with no visual resemblance to a different brand's domain. This decoder still shows the decoded Unicode form for transparency but doesn't flag anything when no confusable substitution pattern is present.
- A domain mixing punycode-decoded characters with ASCII in the same label
- Punycode can encode a label that's mostly ASCII with just one or two non-ASCII characters inserted — a single substituted letter in an otherwise correctly-spelled brand name is actually the most convincing and common homograph pattern, precisely because most of the domain looks completely correct.
- A punycode string that fails to decode cleanly
- Malformed xn-- labels (wrong delimiter, invalid digit encoding) will fail to decode per the punycode algorithm. This decoder reports the specific decode failure rather than silently returning the raw ASCII string as if it were the intended output.
Common mistakes
- Trusting a domain's visual appearance in an address bar without checking whether it decodes from an xn-- form using confusable characters.
- Assuming any xn-- domain is inherently suspicious, when the encoding itself is a normal, standardized mechanism used by countless legitimate non-English sites.
- Registering brand-protection domains only in the exact ASCII spelling, without also registering or monitoring the visually confusable Unicode variants.
- Copy-pasting a suspicious link's domain into a general Unicode viewer without specifically decoding the punycode structure first.