Punycode Converter

Convert internationalized domain names between Unicode and Punycode (ACE) encoding formats.

Tested tool guide Tested browser tools Checked August 16, 2026

What Punycode Converter does, with a checked example

Every label in a domain name must be plain ASCII before it can reach the DNS, so names that use accented or non-Latin characters are stored in an ASCII-compatible encoding called Punycode, recognizable by its xn-- prefix. This tool converts in both directions: type the Unicode name to get its encoded form, or paste the xn-- form to get the name back. The thing most people get wrong: conversion happens label by label. Only the label containing non-ASCII characters changes; ASCII parts like .com or www. pass through untouched, and the xn-- prefix is added by IDNA, not by the encoding itself.

Worked example

A concrete input and expected output from the current implementation.

Input

bücher.de

Expected output

xn--bcher-kva.de

The label bücher contains the non-ASCII character ü (U+00FC), so it encodes to bcher-kva (the worked example from RFC 3492) and IDNA adds the xn-- prefix; the ASCII label de passes through unchanged.

How the result is produced

The encoding (RFC 3492)

The algorithm, called Bootstring, copies the ASCII characters of the label through in order, then appends a compact, variable-length integer that records the positions of the non-ASCII characters so a decoder can splice them back in. The xn-- prefix is an IDNA convention layered on top; the RFC 3492 algorithm itself produces only the part after the prefix, and its design keeps encoded labels short.

Per-label conversion

The tool splits the domain at the dots and converts each label independently. Only labels containing non-ASCII characters are encoded and given the xn-- prefix; ASCII labels pass through untouched, so one label in a name can carry xn-- while its neighbors do not. Converting the same name twice yields the same string, and in the reverse direction the tool recognizes xn-- labels and decodes them, leaving other labels alone.

Good uses

Registering or administering an internationalized domain: DNS records, WHOIS responses, and certificate tooling use the encoded form, and this tool gives you the exact xn-- string to compare against what you registered.
Vetting a link before clicking: decode the xn-- label in a suspicious URL and compare it with the domain you think you are visiting, which catches homograph and lookalike domains that display misleadingly.
Checking your own code: IDNA and punycode libraries exist in most languages, but they differ on edge cases; converting a few reference labels here gives you an independent answer to test against.

Limits and checks

Conversion is per label, not per domain. bücher.de encodes to xn--bcher-kva.de with the prefix on one label only; there is no single punycode value for a whole multi-label name, and partial conversions cannot simply be joined.
Not every string is a valid IDN. Emoji, spaces, underscores, and most symbols cannot appear in an IDN label; IDNA-aware software rejects them, though a bare RFC 3492 encoder will happily produce xn-- output for them, so results on such input depend on which rules the tool follows.
Different IDNA revisions disagree on borderline characters. IDNA2003 mapped ß to ss and stripped diacritics, while IDNA2008 permits ß itself, and UTS #46 supports both modes, so the same input can yield different canonical strings, and a label converted years ago may no longer match today's output.

Common questions

Why does my browser show xn--... instead of the internationalized name?

Modern browsers display the Unicode form only when the label looks safe: characters from a single script, no confusable lookalikes, and in some browsers a secure connection. Labels that mix scripts or could impersonate ASCII are shown as xn--... on purpose, to reduce homograph spoofing. The tool converts the same label either way, so you can always see what the address really is.

Is punycode the same as base64 or percent-encoding?

No. Punycode keeps ASCII characters in place and appends a short encoded value for the non-ASCII ones, so encoded labels stay compact and partly readable. Base64 would expand everything, and percent-encoding would produce longer output with many percent signs. The xn-- prefix comes from IDNA, not from the encoding itself, so do not strip it and expect another scheme to decode the rest.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.