offlineutils
100% offline
Developer
Free · no signup
Updated

Punycode / IDN Converter

A Punycode / IDN Converter turns an internationalised domain name into the ASCII xn-- form that DNS actually carries, and back again, applying the full UTS #46 processing that browsers apply — entirely in your browser.

Defaults match the URL standard, and therefore the address bar. Unicode 17.0.0.

straße.de

xn--strae-oqa.de

This name has two readings

IDNA2008 / every current browser
xn--strae-oqa.de
IDNA2003 / transitional
strasse.de

These are two unrelated registrations. A name containing ß, ς, or a zero-width joiner meant one thing before 2010 and another after, which is why some German domains had to be bought twice.

  • straße→xn--strae-oqa

    Script: Latin. 13 of 63 characters.

  • deunchanged

    Script: Latin. 2 of 63 characters.

About Punycode / IDN Converter

Punycode on its own is not what turns a Unicode domain into an xn-- label. Browsers run a preprocessing pass first — case folding, compatibility mapping, and Unicode NFC normalisation — and a converter that skips it disagrees with the address bar in ways that look plausible. Type café with a combining accent, which is exactly what macOS hands you because its filenames are decomposed, and a naive converter returns xn--cafe-yvc while your browser returns xn--caf-dma: a different domain that resolves somewhere else or nowhere at all. Paste fullwidth ｅｘａｍｐｌｅ.com and it maps to plain example.com, which is why a host allowlist that punycodes without mapping can be walked straight past. This tool implements UTS #46 properly, including the two contextual rules most implementations omit: CheckBidi, which is why a Hebrew or Arabic label with a Latin letter in it is rejected, and CheckJoiners, which is why a zero-width joiner is only legal where an Indic or Arabic script actually needs one. It also enforces the URL standard's forbidden characters, which UTS #46 does not cover — its table calls space valid, and U+FE70 maps to a space, so without that check you get a domain with a space inside it. You get both directions at once rather than picking one, a character-by-character account of what was mapped, removed or rejected and why, warnings for mixed scripts and Cyrillic lookalikes, and the two different readings of any name containing ß or ς.

What Punycode / IDN Converter does

  • Both directions at once — paste Unicode or xn--, get each form
  • Full UTS #46 processing: case folding, compatibility mapping, NFC
  • CheckBidi and CheckJoiners, the rules most converters skip
  • Character-by-character account of every mapping and removal
  • Flags Cyrillic and Greek lookalikes of ASCII letters
  • Warns on labels that mix scripts, the signature of a homograph attack
  • Shows both the IDNA2003 and IDNA2008 reading of names containing ß or ς
  • Reports invisible characters that mapping silently discards
  • Cross-checks the answer against your own browser's IDNA

When to reach for Punycode / IDN Converter

  • Checking what a suspicious xn-- domain in an email or log actually says
  • Confirming an internationalised domain encodes to the label you registered
  • Working out why a Unicode hostname your code accepts is refused by a browser
  • Testing whether a host allowlist can be bypassed with fullwidth or mapped characters

How to use Punycode / IDN Converter

  1. 01

    Paste the domain

    Either form works. A Unicode name is encoded, an xn-- name is decoded, and both forms are shown side by side — there is no direction to choose.

  2. 02

    Read the ASCII form

    This is what DNS carries and what a certificate is issued for. Copy it straight into a registrar form or a config file.

  3. 03

    Check the warnings

    Amber warnings are security notes: a label mixing two scripts, a character that renders like an ASCII letter, or an invisible character that was silently removed.

  4. 04

    Open the character breakdown

    Switch to 'Character by character' to see the status of every code point and exactly what it was mapped to. This is where a surprising result explains itself.

When to use Punycode / IDN Converter vs alternatives

AlternativeUse Punycode / IDN Converter when…Use the alternative when…
A one-line punycode.toASCII() wrapperyou need the answer to match the address bar. Bare Punycode skips the mapping and normalisation pass, so decomposed accents and fullwidth characters come out as different domains.you genuinely want raw RFC 3492 with no IDNA preprocessing.
Your browser's address baryou want to know *why* — which character was mapped, which rule rejected the name, and whether it contains a lookalike.you only need to see whether a name loads.
The `idn` command line toolyou want the homograph and mixed-script warnings, and the per-character breakdown, without installing anything.you are converting names in a shell pipeline.

Frequently asked questions

Why does this give a different answer than other punycode converters?
Because most of them only implement RFC 3492 and skip the UTS #46 preprocessing that browsers apply first. The clearest case is normalisation: 'café' can be stored as four code points with a precomposed é, or five with a combining acute accent. They look identical and macOS hands you the decomposed form, but without the required NFC pass they encode to xn--cafe-yvc and xn--caf-dma respectively — two different domains. Whatever your browser does is the answer that matters, and this tool cross-checks itself against your browser's own IDNA to prove it agrees.
What is a homograph attack?
Registering a name that renders almost identically to a well-known one by using characters from another script. Cyrillic а, е, о, р, с and х are visually indistinguishable from Latin a, e, o, p, c and x in most fonts, so аpple.com with a Cyrillic а is a completely different domain that looks the same. Browsers defend against this by displaying the xn-- form instead of the Unicode one when a name mixes scripts suspiciously. This tool flags both the mixed script and the specific confusable characters, and names them, so you can see exactly which letter is not what it appears to be.
Why is straße.de shown with two different encodings?
Because ß is a deviation character, and the rules changed. IDNA2003 folded ß to 'ss', so straße.de and strasse.de were the same domain. IDNA2008 keeps ß, making xn--strae-oqa.de a separate registration — and browsers moved to the new behaviour around 2010. Final sigma ς and the zero-width joiner and non-joiner behave the same way. It is why some German site owners had to buy their domain twice, and why the tool shows both readings rather than picking one silently.
Why was my domain rejected when it looks fine?
Most often one of the two contextual rules. CheckBidi (RFC 5893) requires a label containing right-to-left text to be consistently right-to-left, so an Arabic or Hebrew label with a stray Latin letter is invalid even though both characters are individually allowed — and because that rule applies to the whole name, one right-to-left label anywhere makes every label answer for it. CheckJoiners (RFC 5892) allows a zero-width joiner only directly after a virama or between two Arabic joining letters, since anywhere else it is invisible and does nothing but make two different names look the same. The character breakdown names the rule and the character.
Can a valid Unicode character still be banned from a domain?
Yes, and by two different specifications. UTS #46 marks a lot of characters 'disallowed' outright. Separately, the URL standard forbids a handful — space, control characters, percent, and the URL syntax characters — that UTS #46's own table calls valid. That gap is not theoretical: U+FE70 ARABIC FATHATAN ISOLATED FORM maps to a space followed by a mark, so a converter that implements only UTS #46 will hand you back a label with a space inside it. This tool applies both sets.
Is it safe to paste a suspicious domain here?
Yes. Everything runs in your browser — the Unicode tables are part of the page and no request is made with what you type, so a domain from a phishing email never leaves your machine and nothing is logged. There is also nothing clickable about the result: it is displayed as text, not as a link.

Related tools

URL Encoder / Decoder

Percent-encode and decode URL components instantly.

URL Parser

Break any URL into its protocol, host, path and query parameters.

Base64 Encoder / Decoder

Encode text to Base64 and decode it back, all offline.

Related concepts