IDN Punycode converter

IDN Punycode converter is a free tool that converts internationalized domain names between readable Unicode text and the ASCII-compatible Punycode form used by DNS.

Why is there an ASCII version of a domain name?

IDNA provides an ASCII-compatible form so internationalized domain labels can work with hostname and application conventions developed before characters from writing systems worldwide were commonly supported. Internationalized Domain Names, usually shortened to IDNs, let people use characters such as é, ü, ñ, or 日 in a domain while preserving an ASCII representation for DNS software.

IDNA processing uses Punycode to convert each eligible non-ASCII domain label into letters, digits, and hyphens, then adds the xn-- ACE prefix. The prefixed result is an A-label only if it is valid under the applicable IDNA rules. Dots remain separators between labels.

A small example is:

Readable form: café.example

Punycode form: xn--caf-dma.example

Punycode is encoding, not encryption. Anyone can convert it back to Unicode, so it provides no secrecy and should not be used to conceal information.

Converting labels in either direction

Use Convert to Punycode/ASCII for a Unicode U-label and Convert to IDN/Text for an ASCII A-label. The tool uses the server-side PHP functions idn_to_ascii and idn_to_utf8 for the conversion.

1. For a name containing international characters, enter it in Convert to Punycode/ASCII.
2. Read the converted value from Punycode/ASCII.
3. For a name containing an xn-- label, enter it in Convert to IDN/Text.
4. Read the readable Unicode version from IDN/Text.

Conversion applies to domain labels, not arbitrary sentences or files. ASCII letters and numbers generally remain readable. Spaces are not valid in DNS hostnames, and punctuation that works in ordinary text may be rejected under IDN or hostname rules. A long Unicode label can also become longer after conversion and exceed the DNS limit of 63 ASCII bytes per label.

The work is done on the server. Your input travels to the server over HTTPS and is not stored.

How can I tell whether the converted domain is usable?

You can check the structure of the result, but conversion alone cannot confirm that a domain is registered, available, or accepted by a particular registry. An ASCII result containing an internationalized label must use the xn-- prefix for that A-label.

• Check every label separated by a dot, including subdomains.
• Make sure no spaces or URL components such as https://, a path, or a query parameter were included.
• Compare the decoded Unicode characters carefully, especially characters that resemble Latin letters.
• Check the registry's language and character rules before trying to register the name.
• Use the ASCII form where software specifically requires a DNS-compatible hostname.

IDNA rules are stricter than the underlying Punycode algorithm. A sequence may be mathematically encodable yet still be unsuitable for a registered domain because of prohibited characters, character combinations, or registry policy.

What should I check when Punycode will not decode?

Check that the input is a valid IDNA A-label, has not been encoded by another method, and contains no copied URL syntax. Common causes of failure or unreadable output include the following. A malformed or invalid A-label is a direct common cause; whether the other listed causes apply depends on the source format:

• The A-label is malformed or invalid. Missing characters, misplaced hyphens, unsupported code points, or copying only part of a label can prevent a valid conversion.
• The wrong encoding was assumed. A value from a query string may be percent-encoded, while an email attachment or JSON field may contain Base64. Those are different alphabets and formats.
• An outer layer remains. An xn-- label represented as percent-encoded data must have that outer URL encoding removed first. The URL decoder can help with that step.
• The data is binary rather than text. Punycode represents Unicode code points in domain labels. It is not a decoder for images, compressed bytes, or encrypted content.

Punycode does not use = padding. Missing padding and URL-safe alphabet differences are usually Base64 problems, not Punycode problems. If someone advised adding padding to an xn-- label, verify the original encoding first.

Where does Punycode fit among other web encodings?

Punycode is specifically for internationalized domain labels, while other encodings solve different transport and syntax problems. Use IDN conversion only for Unicode U-labels and ASCII A-labels, not for other encoded data.

• Browser addresses and DNS records may use Punycode for the hostname while retaining ordinary URL syntax elsewhere.
• Query strings commonly use percent-encoding for spaces, punctuation, and UTF-8 bytes. Use a URL encoder or URL decoder for that layer.
• Data URIs commonly contain percent-encoded or Base64 data. Punycode does not decode their contents.
• Email can use an internationalized domain after the @ sign, but the local mailbox portion follows separate standards and support varies.
• JSON payloads can carry Unicode text directly. A domain inside JSON may still need Punycode when another system uses it as a DNS hostname.
• HTML may use character entities for markup-sensitive characters. The HTML entity converter handles that syntax, which is unrelated to IDN conversion.

Frequently asked questions

Are uppercase and lowercase Punycode domains different?

DNS hostname matching is generally case-insensitive, so uppercase and lowercase ASCII letters do not identify different domains. Lowercase is the conventional form and reduces confusion when copying values between systems.

What happens to subdomains during IDN conversion?

Each dot-separated label is handled independently. A domain can therefore contain an encoded internationalized subdomain alongside labels that remain ordinary ASCII, such as xn--caf-dma.example.com.

Can Punycode create lookalike domain names?

Yes. Characters from different scripts can look similar even though they have different Unicode code points and resolve to different domains. Before visiting or configuring a sensitive domain, inspect the decoded spelling and confirm it through an independent source.

Does a trailing dot belong in the Punycode label?

No. A final dot represents the DNS root and is not part of the preceding label. Some DNS configuration tools use fully qualified names with that trailing dot, while browser addresses commonly omit it.

Can I convert the domain part of an email address?

Yes, the portion after the @ sign can be treated as an internationalized domain. Convert only that domain portion because the mailbox name before the @ sign uses separate internationalized email rules.

Should I save both the Unicode and ASCII forms?

Keeping both can be practical when maintaining DNS records, certificate requests, or documentation. Use the ASCII form for systems that require DNS-compatible input, and keep the Unicode form so people can verify the intended spelling.