1. Home
  2. Developer tools
  3. Punycode Converter

Punycode Converter

DNS only carries ASCII, so the Unicode label münchen travels as xn--mnchen-3ya. Convert a list of domains in either direction and see when a name mixes scripts in a way that could be a homograph trick.

Free, no sign-up. Runs in your browser: nothing is uploaded.

How to use Punycode Converter

  1. Paste domain names, one per line.
  2. The direction is detected for each line.
  3. Copy the converted names.

Features

  • Unicode to xn-- and xn-- to Unicode in one box
  • Per-label conversion of full domain names
  • Single-string Punycode mode without the prefix
  • NFC normalisation and lower-casing first
  • Mixed-script warning for spoofing risk
  • Clear errors for invalid input

Supported formats

Input

  • Domain names
  • xn-- labels

You get

  • Unicode
  • Punycode

Private by design

Everything you enter is processed by your browser on this device. Nothing is sent to openWorkstand or anyone else, so the Punycode Converter is safe for private and work data. After you have used it once while online, it also works without an internet connection. How local processing works

Good to know

  • This is Punycode with basic IDNA steps (lower-casing and NFC), not the full UTS #46 mapping table.
  • Whether a registry accepts a name depends on its own rules.

Guide

Punycode and internationalised domain names

The Domain Name System was built for letters, digits and hyphens. To let people register names in their own scripts, the standards bodies chose an encoding that turns any Unicode label into an ASCII one, and Punycode is that encoding. A domain like münchen.de is stored and looked up as xn–mnchen-3ya.de, and your browser converts it for display. This page shows both forms and converts either way.

How Punycode works

The algorithm, defined in RFC 3492, keeps the ASCII characters of a label as they are and writes them first, followed by a hyphen. It then appends a compact description of where each non-ASCII character goes and which character it is, using variable-length numbers in base 36. For münchen, the ASCII letters mnchen come first, then a hyphen, and the ü is described by the trailing 3ya. A label with only ASCII needs no conversion.

The xn– prefix

To tell a Punycode label from an ordinary one, domain names add the prefix xn– in front of the encoded text. So the label münchen becomes xn–mnchen-3ya. The prefix applies to each label separately: the Russian name пример.рф is xn–e1afmkfd.xn–p1ai, with both labels converted, while a domain such as bücher.example gives xn–bcher-kva.example because only the first label has non-ASCII characters.

Using the page

Paste domain names, one per line. The page detects the direction for each line: if any label begins with xn– it is decoded, and otherwise it is encoded. The results appear on the right in the same order. A second mode treats each line as a single string and converts it without the prefix, which is useful for inspecting the raw algorithm output. Errors, such as a malformed Punycode digit, are reported next to the line they belong to.

Normalisation and case

Before encoding, text is lower-cased and put into Unicode normalisation form NFC, so that a letter written as a base plus a combining mark and the same letter written as one character give the same result. Without this step, visually identical names could produce different Punycode. The page does not apply every mapping rule of UTS 46, such as the special treatment of the German ß or of joiner characters, so unusual names may differ from what a particular registry or browser produces.

Look-alike names

Because many letters of different alphabets look alike, an attacker can register a name that reads as a well-known site. When a single label of a name mixes writing systems, a warning appears. A fully Cyrillic name that looks like a Latin one will not trigger it, so treat the warning as a hint and not a guarantee. If you receive a link you do not trust, converting its host to Punycode shows exactly which characters it contains.

A worked example

The Sample button converts a list. münchen.de gives xn–mnchen-3ya.de, bücher.example gives xn–bcher-kva.example, 日本語.jp gives xn–wgv71a119e.jp and пример.рф gives xn–e1afmkfd.xn–p1ai. The line xn–fsq.jp goes the other way and shows 例.jp. None of these mixes writing systems inside one label, so no warning appears; a label that combined a Latin a with a Cyrillic а would trigger it.

Limits

The converter implements Punycode and the basic preparation steps. It does not check names against the IDNA 2008 tables, registry policies or the public suffix list, and it does not look names up. Whether a domain can be registered or resolved is outside its scope.

Checked against the current version of the Punycode Converter on .

Frequently asked questions

Why does my browser show a domain as xn-- text instead of the real name?

Browsers display the Unicode form only when they judge it safe. If a name mixes scripts, or uses characters that look like Latin letters from a script the user is unlikely to read, the address bar shows the xn-- form so that a look-alike cannot pass for the real site.

Is a name that decodes without errors always a valid domain?

No. Registries have their own rules about which characters and scripts are allowed, and the IDNA standards forbid many code points. A name can be converted correctly and still be refused at registration.

What is a homograph attack?

Registering a domain whose letters look like a trusted one, for example with a Cyrillic а in place of a Latin a. Browsers may show such names in xn-- form for that reason.

Is this full IDNA processing?

It implements Punycode and the usual lower-casing and normalisation, but not every UTS #46 mapping, such as the special handling of ß or joiner characters.

Keep working with the result

openWorkstand also includes a free workspace with documents, spreadsheets, tasks, projects and a calendar that save to a folder on your computer.