Enter a domain to compare its Unicode and ASCII forms. Character findings help review suspicious names but do not establish whether a site is trustworthy.
Runs locally in your browser| Label | ASCII / Punycode | Scripts | Risk |
|---|---|---|---|
| Enter a domain to inspect each label. | |||
For account recovery, certificates, email allowlists, redirects, and security decisions, normalize the hostname and compare the ASCII form using a current IDNA implementation and an application-specific policy.
Type or paste a hostname — Unicode or already encoded — and press Convert & analyze. The tool reduces the input to a hostname, folds case and compatibility forms (NFKC plus lowercase), drops the characters IDNA ignores, and encodes every non-ASCII label as Punycode, so the ASCII line is the form a resolver or an allowlist would actually see.
Punycode labels are decoded and re-encoded on the way: a label that does not round-trip canonically is reported as invalid instead of being printed as garbage. Everything runs in the page, with no DNS lookup and no request to the site; a clean report means no obvious character-level risk was found, not that the domain can be trusted.
The field is treated as a hostname rather than a URL: a leading scheme, a path, a query string and a trailing port are removed, a final dot is dropped, and an IP literal such as [::1] is refused with a message instead of being converted. An empty field is refused as well.
Before encoding, the name is mapped to its canonical form: NFKC folds full-width and compatibility characters, labels are lowercased, and the code points IDNA ignores — zero-width spaces, soft hyphens, byte-order marks, variation selectors, bidirectional controls — are removed. That is the treatment browsers apply before a hostname is used, so münchen.de, MÜNCHEN.DE and a spelling carrying a zero-width space all end up on the same ASCII output.
Each non-ASCII label is then Punycode-encoded and prefixed with xn--. Punycode labels are decoded back and re-encoded as well: when a label does not decode to a canonical Unicode label — xn--a, for instance — the tool reports it as invalid Punycode rather than showing the decoded bytes.
A red finding marks something a browser or resolver would reject, or something that hides a character: a label that starts or ends with a hyphen, a character that cannot appear in a hostname label (underscore, @, spaces), an invalid Punycode label, or a label that exceeds 63 octets after conversion. 253 characters is the limit for the whole ASCII name.
Mixed writing systems inside one label, invisible or bidirectional characters, and common lookalikes — reported together with the simplified skeleton — are the patterns homograph attacks rely on. The risk badge in the table repeats that judgement per label: High when the label is not usable or mixes scripts, Medium when it carries a Punycode prefix or a lookalike, Low for an ordinary ASCII label.
The analysis is character-level only. No DNS record is queried, no certificate is fetched and no registry or reputation source is consulted, so a name can pass every check on this page and still be a registered phishing domain that resolves and serves content.
Use the ASCII form as the value you compare: for allowlists, certificate checks and redirect rules, compare the normalized ASCII hostname — not the Unicode display name — and compare it against the ASCII form produced by the other system. When a decision needs to be registry-accurate, confirm the result with a full UTS#46/IDNA implementation.