Free Punycode Converter
Paste a Unicode domain or an xn-- string. We show you both forms at once, using the same UTS-46 ruleset browsers apply.
Converting...
Could not convert
Use this for display to people.
Use this for DNS, certificates and config.
This name is already plain ASCII, there is nothing to encode, so both forms are identical.
This name carries internationalised characters, so its Unicode and ASCII forms differ. The DNS uses the ASCII form.
What is a Punycode Converter?
A Punycode converter translates a domain between its human-readable Unicode form (münchen.de) and the ASCII form the DNS actually uses (xn--mnchen-3ya.de). The DNS only carries ASCII, so every internationalised domain is stored and resolved in its Punycode encoding.
Paste either form and this tool shows you both, so you can see exactly what a browser, a certificate, a mail server, or a log line is really pointing at. The conversion runs on the same UTS-46 ruleset modern browsers use, and nothing you enter is logged or stored.
- Paste a Unicode domain (with accented or non-Latin characters) or a Punycode string that starts with xn--.
- We convert it both ways at once and show the Unicode form and the ASCII (Punycode) form side by side.
- Copy whichever form you need, the ASCII form for DNS, certificates and config; the Unicode form for display.
Why Convert Punycode?
- The DNS is ASCII-only: an IDN is stored as its xn-- form, so that is the string you need for zone files, certificates, and most APIs.
- Spot a homograph: a name that looks Latin but converts to an xn-- string is carrying non-Latin look-alike characters, the basis of a homograph attack.
- Standards-correct: we use the intl IDNA codec with the UTS-46 ruleset, so the result matches what a browser resolves, not a hand-rolled approximation.
Anatomy of a Punycode Domain
Punycode is not encryption or hashing, it is a reversible encoding with a fixed shape. Here are the parts you will see.
| Part | Looks like | What it is |
|---|---|---|
| The xn-- prefix | xn--mnchen-3ya | The ACE (ASCII-Compatible Encoding) prefix. Any label beginning xn-- is a Punycode-encoded internationalised label; everything after it is the encoded content. |
| The encoded suffix | -3ya, -kva | After the last hyphen sit the codes that reconstruct the non-ASCII characters and where they belong. It is deterministic, the same Unicode always yields the same string. |
| Per-label encoding | xn--… . com | Encoding is per label, not per domain. Only the labels that contain non-ASCII characters get an xn-- form; a plain .com suffix is left untouched. |
| A plain ASCII name | example.com | A domain with only letters, digits and hyphens is already valid DNS. It has no Punycode form to convert to, the two forms are identical. |
| A mixed-script label | аpple.com | A label mixing scripts (here a Cyrillic а with Latin letters) is a red flag: it can read as a familiar Latin name while resolving to a completely different xn-- string. |
How to Read the Result
The converter always shows both forms. Here is what each is for.
The ASCII (Punycode) form
For machinesThe xn-- form is what the DNS resolves and what belongs in a zone file, a TLS certificate's SAN list, a redirect config, or an API call. When something rejects an IDN, this is the string it actually wants.
The Unicode form
For peopleThe human-readable form, for display in a UI, a document, or marketing. Modern browsers show this in the address bar for scripts they trust, and fall back to the xn-- form for ones they do not.
When both forms match
No changeIf you paste a plain ASCII domain, the two forms come back identical, there is nothing to encode. That is the expected result for an ordinary name; it confirms the name carries no internationalised characters.
When a "Latin" name encodes
The warningIf a name that looks like plain Latin comes back with an xn-- form, it is carrying look-alike characters from another script, the mechanism behind homograph phishing. That is worth a second look.
Check its look-alikesWhat Internationalised Domains Are
Internationalised Domain Names (IDNs) let a domain use characters beyond the basic Latin letters, digits and hyphen, accented Latin, Cyrillic, Greek, Arabic, Han, and more. They are what make a domain readable in the language of the people it serves.
The catch is compatibility:
- DNS is ASCII: the protocol predates Unicode, so an IDN has to be encoded to fit.
- Punycode is the bridge: a reversible encoding that maps any Unicode label to a unique xn-- ASCII label.
How the Encoding Works
Punycode (defined in RFC 3492, applied through the IDNA / UTS-46 rules) separates a label's plain-ASCII characters from its non-ASCII ones, then appends a compact, deterministic code describing the non-ASCII characters and the positions they insert into. The xn-- prefix marks the result so software knows to decode it.
Because it is deterministic and reversible, a given Unicode label always produces the same xn-- string and vice versa, which is exactly why a converter can show you both forms from either input, with no lookup and no ambiguity.
Where Punycode Trips People Up
The encoding itself is simple; the confusion is almost always about where the forms belong. The cases that catch people out:
- Certificates and config want the xn-- form, a TLS certificate's SAN list, an Nginx server_name, and most DNS APIs expect the ASCII form. Pasting the Unicode form is a common cause of "domain not found" errors.
- The homograph trap, a Cyrillic а, a Greek ο, or a Latin l/one look identical to their neighbours. A name can read as apple.com and resolve to a different xn-- domain entirely. If a "familiar" name encodes, treat it with suspicion and check its look-alikes.
- Browser display varies, browsers show the Unicode form only for scripts they consider low-risk and fall back to xn-- otherwise, so the same domain can display two ways in two browsers. The encoding is identical; only the display differs.
- Email and older software, some mail servers and legacy tools still choke on IDNs or handle only one form. When in doubt, the ASCII form is the safer one to configure with, and a DNS lookup confirms what actually resolves.
Why the Conversion Matters
Debugging resolution
When an IDN "does not work", the cause is usually a form mismatch, the Unicode name where the ASCII one was needed. Seeing both forms side by side is the fastest way to find which one a system is unhappy with.
Spotting impersonation
Converting a suspicious link is how you unmask a homograph attack: a name that looks like a brand but carries look-alike characters betrays itself the moment it encodes to an unfamiliar xn-- string.
Email & DNS config
Zone files, SPF includes, DKIM selectors, and mail routing all live in ASCII. The xn-- form is the one that belongs in them, and converting it once avoids a class of silent misconfiguration.
Building for the world
If your product accepts domains or emails from a global audience, you will meet IDNs. Converting correctly, with the same ruleset browsers use, is the difference between accepting them and rejecting real users.
Who Converts Punycode
The same conversion answers a different question depending on who is asking.
Developers & IT
Get the exact ASCII form for a zone file, a certificate, or an API that will not take the Unicode name.
For IT & MSPsSecurity Teams
Decode a suspicious link to reveal a homograph or mixed-script domain hiding behind a familiar-looking name.
For brand protectionRegistrars & Resellers
Show customers both forms of an IDN they are registering, and store the ASCII form the registry expects.
For registrarsAgencies
Handle a client's internationalised domains correctly across DNS, certificates, and analytics.
For agenciesRelated Domain Tools
Once you have the form you need, here is where to go next.
Check for look-alikes
If a name encoding to Punycode made you suspicious, run its typo and homoglyph variants to see which look-alikes are registered.
Typosquat checkerLook up the record
A WHOIS lookup on the ASCII form shows the registrar, dates, and status codes behind an internationalised domain.
Run a WHOIS lookupSee what it resolves
A DNS lookup on the xn-- form shows the records the IDN actually points at, the answer to "does this resolve".
Run a DNS lookupMonitor the domain
Put an internationalised domain, or the look-alikes around it, under monitoring so a change reaches you as an alert.
Set up monitoringFrequently Asked Questions
Common questions about Punycode, IDNs, and the xn-- encoding.
What is Punycode?
Punycode is a reversible encoding (RFC 3492) that represents a Unicode domain label as an ASCII string beginning with xn--. Because the DNS only carries ASCII, every internationalised domain is stored and resolved in its Punycode form.
What is an IDN?
An Internationalised Domain Name is a domain that uses characters beyond basic Latin letters, digits and hyphen, for example accented Latin, Cyrillic, Greek, Arabic, or Han characters. IDNs are encoded to Punycode for use in the DNS.
What does xn-- mean?
It is the ACE (ASCII-Compatible Encoding) prefix. Any domain label that starts with xn-- is a Punycode-encoded internationalised label, and everything after the prefix is the encoded content that reconstructs the original Unicode characters.
Does the conversion send my domain anywhere?
The conversion itself is a pure encoding, no registry lookup and no connection to the domain. We do not log or store the text you enter.
Which ruleset do you use?
We use the intl IDNA codec with the UTS-46 ruleset, which is the modern standard browsers apply. That means the result matches what a browser actually resolves, rather than a hand-rolled approximation.
Why do both forms sometimes come back the same?
Because the domain is already plain ASCII, only letters, digits and hyphens, so there is nothing to encode. Identical forms confirm the name carries no internationalised characters.
What is a homograph attack?
It is registering a domain that uses look-alike characters from another script, a Cyrillic а for a Latin a, for instance, so it reads like a trusted name but resolves to a different xn-- domain. Converting a suspicious name exposes it, because it will encode to an unfamiliar Punycode string.
Which form do I put in a TLS certificate or zone file?
The ASCII (xn--) form. Certificates, zone files, most DNS APIs and mail configuration expect the ASCII encoding; the Unicode form is for display to people.
Why does the same IDN show differently in different browsers?
Browsers display the Unicode form only for scripts they consider low-risk and fall back to the xn-- form otherwise. The underlying domain is identical in both, only the display differs.
Can I convert a whole URL, not just a domain?
Yes. If you paste a full URL, we take the host part and convert that; the scheme and path are ignored. Only the domain labels are encoded, and only the ones that contain non-ASCII characters.
Is Punycode the same as URL encoding?
No. URL/percent-encoding (%20 and friends) applies to the path and query of a URL. Punycode applies specifically to domain labels in the host, and uses a completely different, IDNA-defined algorithm.
Do search engines treat IDNs and their Punycode form the same?
Yes, they are the same domain, and the two forms are interchangeable. Search engines index the canonical domain regardless of which form a link uses.
Start Monitoring & Catching Domains Today
Join founders, agencies, and domainers already protecting their portfolio. Your first 5 domains are free.
No credit card required • Cancel anytime
Guides for domain operators
Deep dives on domain names, DNS, SSL, acquisitions and portfolio management.
All guides →
Do Exact Match Domains (EMDs) Still Work? How to Find & Grow Them
Do exact match domains (EMDs) still work in 2026? Discover current SEO ranking data, AI search impact, and how to acquire and grow an EMD with Domainyze.
How to Catch Domains with Hidden Expiry Dates
WHOIS won't show the expiry date for .de, .ai, .nz and other domains. Here is how to monitor domain expiration behaviorally, with no registry dates required.
Do All Pending Delete Domains Go Through Auctions?
Learn why not all pending delete domains go to auction. Explore pre-release sales, dropcatching mechanics, and multi-backorder bidding rules across registrars.