🌐 Punycode / IDN Converter

Convert internationalized domain names (e.g. 日本語.jp) ⇔ Punycode (e.g. xn--wgv71a119e.jp) in both directions. Paste a full URL — each label is converted automatically.

100% Free No signup Browser-only 5 languages Dark mode

🔒 About Privacy

・All processing happens entirely in your browser
・Your input data is never sent to any server

Input (domain or URL)

Output (Punycode ⇄ Unicode)

📖 How it works

If the input contains dots (.), each label is converted independently.
URLs with a scheme like https:// and a path: only the host portion is converted.
Labels with ASCII only are automatically identified as "decode (xn-- → Unicode)"; labels containing non-ASCII are identified as "encode (Unicode → xn--)".
Bootstring (RFC 3492) implemented in pure JavaScript. No external library required.

📖 Where people get stuck

Converts internationalized domain names and Punycode in both directions using the RFC 3492 Bootstring algorithm. It decides label by label, splitting on dots, so you can paste a whole URL and only the host is converted. Everything runs in the browser and nothing is transmitted. What this tool does is encoding, and only encoding — it does not judge whether the domain is registrable or safe. The character restrictions of IDNA2008 and UTS-46, the ban on mixing scripts, and each registry rules of its own are all applied at a later stage, separately from this conversion.

Case	What happens	What to do
A different domain that looks identical (homograph)	Many writing systems contain characters indistinguishable from Latin letters. `U+0430 CYRILLIC SMALL LETTER A`, for example, is drawn identically to the Latin `a` in most fonts. A domain that uses it as its first character encodes to `xn--pple-43d.com`, yet the address bar may display it with the same spelling as the real thing. Browsers switch to the Punycode display under conditions such as mixed scripts within one label or a script that does not match the display language, but those criteria differ between browsers and depend on the user language settings. So the fact that it looked like ordinary spelling on your screen guarantees nothing.	The `xn--` form is the only evidence you have. Paste the suspicious link here and read the output. If a domain that looks like plain ASCII produces an `xn--` result, it contains non-Latin characters. The reverse works too: paste the `xn--` form and you can read the actual string. If you are defending an organization, filter mechanically rather than visually — flag URLs containing `xn--` at the mail gateway or in chat, and keep an allowlist of the domains your work actually uses. Human inspection can be defeated by design, so training alone does not constitute a defense.
Converting is not the same as registrable or reachable	Encoding is a mechanical operation, so any string converts successfully. DNS, however, imposes limits of its own. The 63-character ceiling per label applies to the encoded form, and the four characters of `xn--` count toward it. Since kana and Han characters expand to roughly 1.2 to 1.5 characters each, the practical ceiling in Japanese is about 15 to 20 characters. Beyond that, emoji domains that passed under IDNA2003 are forbidden under IDNA2008, and only a handful of TLDs still accept them. Properly, uppercase and full-width characters are normalized by UTS-46 before encoding, but this tool encodes exactly what you type — a full-width `Ａ` does not become `a`, it is encoded as a non-ASCII character.	DNS only ever sees the `xn--` form. To check reachability, hand the conversion result straight to `dig xn--wgv71a119e.jp` or `whois xn--...`. When a lookup in the Unicode form fails, you cannot tell whether the domain is unregistered or the tool simply cannot handle IDNs. Length works the same way: the number to count is the length after conversion — if the output exceeds 63 characters, no registrar anywhere can register that domain. Before you actually buy one, check the IDN policy of the registry (its table of permitted characters) rather than the search box of a registrar, because the permitted character set differs from TLD to TLD.
The two forms drift apart in mail, certificates and logs	To DNS, the Unicode form and the `xn--` form are the same domain, but to anything that compares strings they are two different values. A TLS certificate carries the `xn--` form in its SAN entries, so matching it against the Unicode string fails. Access logs, analytics and Search Console differ in which form they record, and the same site splits into two rows. Mail is worse still: the domain part can be `xn--`, but making the local part (left of the @) non-ASCII requires SMTPUTF8 (RFC 6531), and MTAs without support for it are still not rare.	Store and compare only the `xn--` form, and restore the Unicode form purely for display — enforcing that in one place is the only real answer. Normalize to `xn--` immediately before writing to the database, before writing a log line, and before handing the value to an external API. Normalizing on only one side is the worst outcome: redirects and links loop forever, and one user appears to be two. For Search Console, the reliable approach is to register both properties and add the figures together. If you accept email addresses, deciding that non-ASCII local parts are unsupported for now and saying so on the form is kinder than accepting them halfway and failing at send time.

Punycode is neither encryption nor obfuscation. Bootstring is a reversible encoding with no key and no randomness — anyone can undo it in a second. Any design that assumes xn-- makes something unreadable will fail. There is a second consequence of working label by label: the attacker can use it too. In the pattern example.com.xn--...., a real domain is placed on the left as a subdomain and the xn-- appears only in the rightmost label. Ownership of a domain is always decided by the rightmost label, the one next to the TLD, and whatever sits to the left of it is irrelevant. When you judge a hostname, read it from the right.

📖 How to Use

1

Paste a domain

Paste an internationalized domain (e.g. 日本語.jp) or a Punycode form (xn--wgv71a119e.jp). Full URLs work too.
2

See the converted result

If the input contains non-ASCII it is encoded to xn--; if ASCII-only it is decoded back to Unicode.
3

Copy and use

Use Copy to send the result to the clipboard. Useful for WHOIS lookups, DNS records, and mail server settings.

❓ Frequently Asked Questions

What is Punycode?

A DNS encoding (RFC 3492) that represents Unicode using only ASCII. Labels starting with xn-- are Punycode-encoded internationalized domain names.

Can I convert emoji domains?

Technically yes, and this tool will encode them, but most TLDs no longer accept emoji labels so usefulness is limited.

How is this different from browser URL.host?

Browser implementations vary — some auto-convert IDN to xn--, others leave Unicode. This tool follows RFC 3492 strictly and converts explicitly.

🔗 Related Tools

🐛 Found a bug or issue with this tool?

Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.