Free tool
What does this domain name look like in Punycode?
DNS carries ASCII and nothing else: “hôtel.example” travels as “xn--htel-vqa.example”, and that is the form a DNS zone, a certificate or an MX record needs. Paste a name in either direction and you get both forms, label by label, with the length of each and any character posing as a Latin letter.
Whatever you paste is decoded by your own browser. It is never sent to a server, not even ours: not the certificate, not the request, not the domain name.
The two checks this tool adds to the conversion
Length first. An accented name grows as it is encoded, and “crème-brûlée” goes from twelve characters to twenty-two. Past 63 the label cannot be registered, and you find that out at checkout, not before. Look-alike characters second. A Cyrillic “а” reads as a Latin “a”, and that one substitution is how someone registers a name that passes for yours. A plain conversion tells you neither.
A name that looks like yours is worth watching
A look-alike domain does nothing while it sleeps. It turns into a problem the day it carries a mail server, a certificate and a login page copied from yours. All three of those are visible from the outside, and they are what DomainVigil watches on the domains it is given: a certificate showing up, an MX record, a change of name servers.
How it works
Two names, only one written in Latin letters
DNS carries nothing but ASCII, and that invisible translation is what makes look-alikes possible. The two lines below render identically in any font. Only one of them is written in the alphabet you think you are reading.
Which of the two contains only Latin letters?
The first
example.com
The second
exаmple.com
Take your time. Zoom in if you like — neither line gives anything away.
Both names sit under example.com, a domain reserved for demonstrations. To convert your own, use the field at the top of the page.
What the screen does not show
The eye is not proof.
Two domain names can look exactly alike on screen. Their ASCII forms do not — and the ASCII form is the one machines read.
- 21look-alike characters flagged
- 63characters per label, once encoded
- 253characters for the whole name
Reading the result
Both forms get equal billing, because the one you need depends on where you are about to paste it. The table below reads the result back, label by label.
- Unicode form, ASCII form
- The same name, written twice. The Unicode form is what a human reads; the ASCII form is what DNS carries. They point at exactly the same record — these are not two domains, and there is nothing to register twice.
- Label by label
- A domain name is not encoded in one piece but label by label, between the dots. That is why “café.fr” becomes “xn--caf-dma.fr” and not “xn--café.fr”: only the label that carries the accent gets encoded, and the suffix is left alone.
- Length exceeded
- The length column counts the characters of the ASCII form, the only one DNS cares about. Past 63 for a label, or 253 for the full name, the name cannot be registered — and encoding almost always adds characters.
- Mixed scripts
- A label that mixes Latin with Cyrillic, or Latin with Greek, is never a legitimate name — that is how look-alike domains are built. The script column names the ones it found.
- Look-alike characters
- Some characters from other scripts are drawn exactly like a Latin letter. Each one is flagged under its label with its Unicode code point and the letter it imitates. A name written entirely in one other script is valid and usually legitimate; using one to copy a Latin name is not.
- Nothing to convert
- The name is already ASCII and carries no xn-- prefix, so both forms come out identical. The structural checks still run: an underscore or a trailing hyphen gets flagged either way.
Five errors that trace back to an internationalized name
They all have the same shape: somewhere in the chain, software expected ASCII and got Unicode.
The DNS zone refuses the accented name
What causes it: Hosting panels do not always encode what you hand them. The field expects a host name, which means ASCII, and an “é” is simply invalid there.
What fixes it: Paste the ASCII form, the one starting with xn--. It is the same name: the record you create will answer for the accented spelling.
The CA refuses to issue a certificate for the accented name
What causes it: The dNSName field of a certificate is an IA5 string, which means ASCII (RFC 5280 § 4.2.1.6). An accented name does not fit there as typed.
What fixes it: Put the ASCII form in the request. The certificate still covers the accented name, because it is the same name — and the CSR decoder in this family of tools shows you what your request really carries.
The encoded name exceeds the allowed length
What causes it: Encoding adds the xn-- prefix plus a run of characters for every non-ASCII sign. A fifty-character name with four accents goes past 63 without trying.
What fixes it: Check the length column before you order the name. The only way out is a shorter label — the 63 limit is in the protocol, and no registry works around it.
Mail goes out to an accented domain and never arrives
What causes it: The name in the MX record and in the SMTP envelope has to be ASCII. A sending server that hands over the Unicode form is left with a name that does not resolve.
What fixes it: Publish and reference the ASCII form everywhere — in the MX, in the SPF, in the DKIM. Showing the accented spelling is an interface matter, not a transport one.
A client says they received an invoice from a domain “that looks like yours”
What causes it: Someone registered a neighboring name, either by swapping a letter for a character from another script drawn the same way, or by changing a single Latin character.
What fixes it: Paste the exact name the client received into this tool: the ASCII form and the flagged characters show at once that it is not your domain. Keep that ASCII form — it is what goes into a complaint.
The traps of an internationalized name
Nine cases, all of them seen in production, with the rule behind each one.
| The trap | What happens | What to do |
|---|---|---|
| The xn-- prefix | It marks an encoded label (RFC 5891 § 4.2.3.1). What follows is not readable text, it is the output of a computation. | Never edit one by hand: change a single character and the label stops decoding. |
| Length after encoding | The label grows: “crème-brûlée” is twelve characters and twenty-two once encoded. | Check the length column. The limit is 63 per label and 253 for the whole name (RFC 1035 § 2.3.4). |
| Two scripts in one label | “аpple” written with a Cyrillic “а” displays as “apple”. The name looks right and points somewhere else. | Be suspicious of any Latin-Cyrillic or Latin-Greek mix: no legitimate name needs one. |
| Look-alike characters | Roughly twenty Cyrillic and Greek characters are drawn exactly like a Latin letter. | Compare the ASCII forms, not what is on screen. Two names that look alike have very different ASCII forms. |
| The two ways of writing an accent | “é” is written either as a single character or as “e” followed by a combining accent. Both look the same on screen. | Nothing to do: IDNA requires the composed form (NFC) before encoding, and this tool applies it. Both inputs give the same xn--. |
| Capital letters | A domain name is case-insensitive, but the encoding is not: the label has to be lowercased first. | Nothing to do either: lowercasing is applied before encoding, as RFC 5891 § 4.2 requires. |
| A hyphen at either end | A label may neither start nor end with a hyphen. | Fix the name. This one usually shows up after an automatic truncation. |
| The underscore | DNS accepts it for a service record (_dmarc, _acme-challenge), not for a host name. | Take it out of any name meant to carry a site or a certificate. |
| The trailing dot | “example.com.” with a trailing dot is the absolute form, valid in a zone file. | Strip it before you compare two names: this tool ignores it, plenty of other software does not. |
The look-alike characters that actually get used
These are exactly the ones the tool flags. Each row gives the character, its Unicode code point and the Latin letter it is drawn to pass for.
| Character | Code point | The letter it imitates |
|---|---|---|
| а | U+0430 — Cyrillic a | a |
| е | U+0435 — Cyrillic ie | e |
| о | U+043E — Cyrillic o | o |
| р | U+0440 — Cyrillic er | p |
| с | U+0441 — Cyrillic es | c |
| у | U+0443 — Cyrillic u | y |
| х | U+0445 — Cyrillic ha | x |
| і | U+0456 — Ukrainian i | i |
| ѕ | U+0455 — Cyrillic dze | s |
| ј | U+0458 — Cyrillic je | j |
| һ | U+04BB — Cyrillic shha | h |
| ԁ | U+0501 — Komi de | d |
| ӏ | U+04CF — Cyrillic palochka | l |
| ο | U+03BF — Greek omicron | o |
| α | U+03B1 — Greek alpha | a |
| ε | U+03B5 — Greek epsilon | e |
| ρ | U+03C1 — Greek rho | p |
| ν | U+03BD — Greek nu | v |
| ɡ | U+0261 — script g | g |
| ı | U+0131 — dotless i | i |
| ǀ | U+01C0 — dental click | l |
The list is not exhaustive — Unicode records thousands of these in its confusables table. This one keeps the characters actually used to copy a Latin domain name, and it is the list the tool applies.
Frequently asked questions
What is Punycode?
An encoding that writes any Unicode string using only the characters a domain name allows: unaccented letters, digits and the hyphen (RFC 3492). A label encoded that way gets the xn-- prefix, which is what makes it recognizable. This is the mechanism that made accented names possible without changing DNS itself, which has never carried anything but ASCII.
Why does my accented domain show up as xn-- in some software?
Because that software shows what the protocol carries and never decodes it. Plenty of admin panels, server logs and mail clients work that way. Some browsers do it on purpose when a label mixes scripts: showing the raw form is the only way left to make clear that the name is not what it appears to be.
Do I need to register both forms of an accented name?
No. They are two spellings of one name: “xn--htel-vqa.example” IS “hôtel.example” — the same record, the same zone, the same certificate. The unaccented version is a different name, and that one you do register separately if you want it. It is also the one most visitors will type.
Can a certificate cover an accented name?
Yes, in its ASCII form. The dNSName field of a certificate is an IA5 string, so ASCII only (RFC 5280 § 4.2.1.6): the xn-- form is what goes in there, and a browser encodes the address bar name the same way before comparing. A certificate that carries the accented spelling in plain text is malformed.
How do I spot a fake domain imitating mine?
By comparing the ASCII forms, never what is on screen. Two names that look identical can have completely different ASCII forms, and that is the tell: if a name you received converts into something starting with xn--, it holds at least one non-Latin character. This tool also flags mixed scripts inside a single label, which never happens by accident.
Is the conversion reversible?
Yes, exactly: the RFC 3492 algorithm is bijective on valid labels, and decoding gives back the original string character for character. You can check it right here — convert an accented name, paste the result back in, and you land on the name you started from.
Display and transport
What you read, what is registered
Six cases where the screen and the zone file say different things. On the left what you see, on the right what encoding turns it into.
On screen
Once encoded
“аpple” written with a Cyrillic “а” displays as “apple”.
The name looks right and points somewhere else. Its ASCII form starts with xn--: the two names have nothing left in common.
“café.fr” carries an accent, so its encoding must be “xn--café.fr”.
A name is encoded label by label, between the dots: it comes out as “xn--caf-dma.fr”, and the suffix is left alone.
“crème-brûlée” is twelve characters, well under the limit.
Twenty-two once encoded. The 63 limit applies to the ASCII form, never to what you type.
“é” is “é”: there is only one way to write it.
There are two: a single character, or “e” followed by a combining accent. IDNA requires the composed form before encoding, and both inputs give the same xn--.
A domain name is case-insensitive, so capitals change nothing.
In use, no. In encoding, yes: lowercasing is applied first, as RFC 5891 § 4.2 requires.
“example.com.” and “example.com” are the same name.
Yes, and the trailing dot is the absolute form used in a zone file. This tool ignores it; plenty of other software does not.
The question that keeps coming back
Do I need to register both forms of an accented name?
No
They are two spellings of one name. “xn--htel-vqa.example” IS “hôtel.example”: the same record, the same zone, the same certificate. There is nothing to create twice, and nothing to renew twice.
Three things not to confuse
The unaccented version
“hotel.example” is a different name, and you register it separately if you want it. It is also the one most visitors will type.
The name written in another script
A label that mixes Latin and Cyrillic is never legitimate. That one belongs to someone else, and its ASCII form is what goes into a complaint.
The form to paste everywhere
In a zone, an MX, an SPF, a certificate request: the ASCII form. The accented spelling is an interface matter, not a transport one.
Twenty checks, no sign-up
- What is my certificate request actually asking for?
- What is inside this certificate?
- Has my DNS change propagated yet?
- Build your SPF record
- Is this domain blacklisted?
- What security headers does this site send?
- A domain's full health report
- When does this domain expire?
- Is this SSL certificate valid, and when does it expire?
- Are your SPF, DKIM and DMARC set up right?
- Is this domain or its mail server blacklisted?
- Which servers receive mail for this domain?
- Which nameservers answer for this domain?
- What do this domain's TXT records do?
- Where does this CNAME end up?