Punycode / IDN Converter

Overview

Converts internationalized domain names to their ASCII punycode form - turning Unicode hosts into xn-- labels that DNS can carry - using the browser's own URL parser for the conversion. One honest caveat: the decode direction is a no-op in WHATWG-conformant engines, as explained below.

How It Works

Choose the direction with the two buttons, type a domain, and read the result card. Encoding applies the browser's IDNA processing: type an umlaut-bearing .de domain and receive the xn-- form, click to copy. The decode direction accepts a punycode label and runs it through the same conversion path. Invalid input shows Invalid rather than a guess.

Step-by-Step Usage Guide

1. Select Domain to Punycode, type the internationalized domain, and copy the xn-- result for DNS or certificate use.
2. Verify encoded output by pasting it into a browser address bar - the browser will display it in whatever form it renders IDNs.
3. For decoding, note the tool's limitation: the URL parser's hostname is always ASCII, so the Unicode form requires a dedicated toUnicode tool.
4. When inspecting a suspicious link, convert its host to punycode yourself and compare letter by letter against the real domain.

Technical Specifications & Standards

Punycode (RFC 3492) is the bootstring encoding that lets the DNS - which carries only ASCII letters, digits and hyphens - represent internationalized labels; IDNA (RFC 3490, later IDNA 2008 and Unicode UTS 46) defines when and how to apply it, and every encoded label wears the xn-- prefix so processors can spot it. This tool delegates to the strongest converter available in a browser: new URL('http://' + input).hostname, which runs the URL standard's host parsing, including full IDNA toASCII with UTS-46 mapping - case folding, normalization, validation. The delegation has one consequence you must know: the WHATWG URL standard serializes hosts in ASCII form, so hostname always returns punycode - which makes the encode direction exact, and the decode direction return its input unchanged in conformant engines. To get the Unicode form of a label you need a dedicated IDNA toUnicode implementation. The security relevance is real: the xn-- prefix is also how homograph attacks hide - a Cyrillic-mixed lookalike of a familiar domain renders deceptively in some fonts - so being able to convert and inspect these labels is a phishing-analysis skill, not just an i18n chore.

Targeted Use Cases

• Registering or configuring a domain with non-ASCII characters, where the registrar and DNS need the xn-- form.
• Analyzing a suspicious URL whose label looks slightly wrong - converting to punycode exposes mixed-script lookalikes.
• Setting up certificates or server_name directives that require the ASCII-encoded hostname.
• Learning how IDNA and RFC 3492 fit into the URL standard's host parsing.

Notes & Gotchas

• Use the encoded xn-- form anywhere a protocol expects ASCII: DNS records, SNI certificates, HTTP Host headers.
• Treat unexpected xn-- labels in links as a phishing signal worth inspecting - legitimate IDNs are common, but so are lookalikes.
• For Unicode decoding, use a tool with IDNA toUnicode support; this tool's URL-parser path returns punycode unchanged.
• Remember mapping rules matter: UTS-46 case-folding and normalization mean two visually similar inputs can encode identically - and that is by design.

Frequently Asked Questions