A hostname can look familiar while containing different characters. It can also look strange in its ASCII form while representing an ordinary internationalised name. To inspect it properly, separate the URL parser's hostname, the domain labels and the human-readable presentation.
Conversion between Unicode and Punycode is a representation operation. It does not determine who owns the domain, whether a page is trustworthy or whether two similar-looking names belong to the same organisation. Use conversion to expose the exact name, then apply the trust checks appropriate to your task.
Extract the host before examining its labels
The domain name inspector helps examine hostname syntax and internationalised representation. When the input is a complete URL, first use the URL inspector to identify its parsed host. Do not infer the host from the most recognisable text in the address.
A URL can contain a scheme, user information, hostname, port, path, query and fragment. Text in the path or user-information section is not the destination host. For example, https://trusted.example@other.example/ has other.example as its hostname. The familiar name before the at sign does not control the network destination.
Use a standards-based URL parser for web URLs. Hand-written splitting rules often mishandle IPv6 brackets, percent encoding or user information. Preserve the original input and the parsed result when reviewing a suspicious or malformed address so the transformation remains visible.
Read labels from the right boundary
DNS names consist of labels separated by dots. A name such as login.accounts.example contains multiple labels; the entire suffix matters. A familiar word at the beginning is not evidence that the domain is owned by that brand.
The registrable domain is not always the last two labels. Public suffixes can contain more than one label, and private suffix arrangements complicate the picture. If an application needs to group sites by registrable domain, use an appropriate maintained public-suffix implementation rather than a split-and-take-two rule.
A trailing dot can express an absolute DNS name. Web URL handling and cookie rules have their own details, so do not freely add or remove punctuation in security-sensitive comparisons without a defined canonicalisation policy. The intended namespace and parser should be clear.
| Observation | What it tells you | What it does not tell you |
|---|---|---|
| ASCII label starts xn-- | It may be an internationalised A-label | Whether the owner is malicious |
| Unicode name looks familiar | The glyphs resemble a known name | Whether the code points or owner match |
| Parser accepts the hostname | It passes that parser's syntax rules | Whether it exists in DNS |
| DNS returns an address | A resolver supplied a mapping | Whether the website is safe |
| TLS certificate matches | The connection meets identity checks | Whether the business is the one you intended |
Understand what Punycode encodes
Internationalised domain processing maps supported Unicode labels into an ASCII-compatible form for use in DNS. Punycode is part of that representation. An A-label begins with xn-- and encodes a corresponding internationalised label when valid under the applicable rules.
Not every arbitrary Unicode string is a valid domain label. IDNA rules and browser processing address permitted characters, contextual requirements and normalisation-related behaviour. Different libraries or processing profiles can reject or map input differently, so record which implementation your application uses.
A successful conversion does not make visually confusable characters equivalent. Letters from different scripts can look similar while representing different code points and different names. Conversely, legitimate names in many languages naturally contain non-ASCII characters and should not be labelled suspicious solely for that reason.
Review an internationalised domain without guessing
Take a name supplied in a support ticket. Preserve the original text, parse it as the expected input type and display both the Unicode form and the ASCII hostname produced by the parser. Compare the complete ASCII value with a trusted reference obtained independently, such as the organisation's saved official address.
If the names differ, identify which label differs. Do not compare only the first few characters or remove punctuation until the values look similar. A name can contain a correct-looking brand label under an unrelated suffix, and a screenshot can hide character distinctions.
For an application allowlist, compare the canonical host according to a documented policy. An exact allowed host and all its subdomains are different permissions. If subdomains are allowed, enforce a label boundary; a plain string suffix check can accept names that merely end with the same letters.
// Example policy for a known canonical ASCII hostname:
const allowed = host === 'example.com' ||
host.endsWith('.example.com');This example assumes host has already been parsed and canonicalised for the application's purpose. It is not a complete URL-fetching security policy: schemes, ports, redirects and resolved addresses may also require restrictions. Keep those controls separate and explicit.
Check limits in the correct representation
DNS label limits are measured in octets in the DNS representation, not by how many glyphs appear on screen. An internationalised label can become longer when converted to its ASCII form. A user interface that counts only visible characters can therefore accept a name that fails later processing.
Validate the converted labels and the full name according to the intended protocol. Avoid silently truncating an overlong name. Truncation changes the destination and can turn a clear validation error into a confusing request to a different host.
Do not reuse host-label validation for every DNS owner name. Some DNS records use labels such as _dmarc or _domainkey for service-specific purposes. A rule designed for ordinary hostnames can reject valid record names if applied without considering the record's role.
Design a display that preserves the destination
For a security review interface, make the hostname visually distinct from the path and show the ASCII representation when useful. Allow users to copy the exact parsed value. A shortened label with the important suffix hidden behind an ellipsis is a poor basis for a trust decision.
Browser address bars apply their own internationalised-domain display policies. A name may appear in Unicode in one context and Punycode in another. That difference can reflect display rules, not a change in the actual domain. Compare the parsed hostname rather than screenshots alone.
Handle bidirectional text carefully in logs and interfaces. Keep field boundaries explicit and use appropriate text-direction isolation so a value does not visually rearrange surrounding labels. Preserve the underlying string for analysis instead of relying exclusively on how it is rendered.
Separate syntactic acceptance from ownership
A syntactically valid name may be unregistered, lack the requested record or belong to an unrelated owner. DNS resolution adds evidence of a mapping, while certificate validation adds evidence about a connection. Neither step proves that the domain is the organisation the user intended to contact.
For a sensitive action, begin from a trusted saved address or an independently verified channel. A tool can reveal structure and encoding, but it cannot infer the user's intended business from the appearance of a string. Keep that distinction visible in any review result.
If a domain changes during a workflow, inspect the redirect chain and the purpose of the new host. Authentication, payment and content delivery can involve legitimate separate domains, but the relationship should be established through the application's documented flow rather than visual similarity.
Preserve the original label for support
When a customer reports that a domain was rejected, retain the submitted string in a restricted diagnostic and show its code points where needed. A copied screenshot can conceal a non-breaking space or a visually similar character. Compare the parser input with the canonical ASCII output and the validation error. This helps distinguish an input mistake from an unsupported label without labelling every non-ASCII name suspicious or silently changing the requested destination.
Frequently asked questions
Are all xn-- domains dangerous?
No. The prefix is used for internationalised labels and supports legitimate names in many languages. Review the complete name and its relationship to the intended service. Treating all internationalised names as malicious would confuse an encoding mechanism with a judgment about the domain owner.
Why does the browser show a different spelling?
It may display an ASCII form under its internationalised-domain safety rules, or it may normalise supported input during URL parsing. Preserve both the original and parsed values when diagnosing the difference. The exact hostname used for the request is more useful than the address bar's presentation alone.
Can I identify the registered domain by taking two labels?
That rule fails for multi-label public suffixes and other arrangements. Use a maintained public-suffix implementation if the task requires registrable-domain boundaries. Also decide whether private suffix entries should apply to your use case, because grouping tenants incorrectly can create security and privacy problems.
Should domain comparisons ignore case?
Ordinary DNS names are compared without case distinctions, but internationalised input still needs the appropriate processing before comparison. Use a parser and canonicalisation policy suited to the protocol. Do not extend hostname rules to URL paths or query values, where case can have different meaning.
Does this tool visit the domain?
Syntax and representation inspection does not establish live destination behaviour. Use the appropriate DNS or TLS tool when you need those separate observations, and keep each result attributed to its measurement. A local conversion result should never be presented as a reputation scan or proof that a destination is safe.