Why DNS needs Punycode
Hostnames in DNS are limited to letters, digits and hyphens, a rule older than Unicode. Internationalised Domain Names (IDNA) work around it without changing DNS: the application converts each non-ASCII label to an ASCII form before any lookup, and that ASCII form is what resolvers, registries and certificates see. Punycode, defined in RFC 3492, is the encoding used for that step, and every encoded label carries the xn-- prefix so software can recognise it.
The encoding is compact rather than obvious. It copies the ASCII characters of a label first, adds a hyphen separator if there were any, and then appends a short run of letters and digits that records where each non-ASCII character goes and what it is. That is why münchen becomes mnchen-3ya: the plain letters survive, and 3ya encodes the position and value of the ü.
What the converter does with each line
Each line is trimmed and split at the dots, with the full-width and ideographic full stops used in Japanese and Chinese text treated as dots too. Every label is Unicode-normalised to NFC and lowercased, then encoded only if it contains a character outside ASCII. Labels that already start with xn-- are decoded instead. The cards show both forms whichever one you typed, so a list can mix directions freely.
From the default input, münchen.de becomes xn--mnchen-3ya.de, bücher.example becomes xn--bcher-kva.example, and user@例え.jp keeps its mailbox name while the domain becomes xn--r8jz45g.jp. The fourth example runs the other way and decodes xn--80ak6aa92e.com to its Cyrillic imitation of apple.com.
The conversion is simplified IDNA. It does not apply the full IDNA2008 mapping tables, does not reject disallowed characters or mixed-script labels, and does not enforce the 63-octet label limit. Before registering a name, confirm the final form with the registry, which applies the TLD's own character policy.
Reading errors and odd results
A line in red means a label starting with xn-- could not be decoded. Invalid Punycode: truncated input means the encoded part ended early, usually a name cut off when copied. Invalid Punycode character means a character outside the letters, digits and hyphen the encoding allows, such as _ or a stray space. Fix the label and the card reappears.
A line that comes back unchanged contains only ASCII and no xn-- labels, so there was nothing to convert. Uppercase input is lowercased on the way through, because DNS names are case-insensitive and Punycode needs a consistent case to encode correctly.
- Check that the xn-- prefix has two hyphens. xn-mnchen-3ya is not a valid IDN label.
- Decode suspicious links before clicking: a Cyrillic а in place of a Latin a looks identical in most fonts.
- Keep the ASCII form in configuration files. Many tools misread raw Unicode.
Where the ASCII form goes
DNS itself only ever stores the xn-- form, so use it in zone files, CNAME and MX targets and when you query the DNS Lookup or WHOIS Lookup. Certificates are the same: a certificate for an IDN lists the xn-- name in its subject alternative names, so generate the request with that form in the CSR Generator.
Browsers decide for themselves which form to display. Most show the Unicode name when a label's characters come from a single script they consider safe, and fall back to the xn-- form when scripts are mixed or confusable, as an anti-spoofing measure. If your legitimate IDN shows as xn-- in a browser, that policy is the usual reason.
Limits and privacy
Conversion happens entirely in your browser. Nothing you paste is sent to DNSfinder. The tool processes the first 200 non-empty lines and ignores the rest, so split very large lists. It does not check whether a domain exists or is registered. For that, run the ASCII form through Domain Availability.