Internationalized domain names let DNS labels represent writing systems beyond ASCII, but the process is more constrained than simply converting an arbitrary Unicode string to Punycode. IDNA2008 defines a protocol and validity rules; UTS #46 defines compatibility preprocessing used by clients. Neither guarantees that a displayed internationalized label cannot resemble a different trusted domain.
Separate the human-facing label and DNS wire form
An IDN U-label is a valid Unicode representation of a DNS label according to IDNA rules. An A-label is its ASCII-compatible form, often beginning xn-- and encoding Unicode content via Punycode. The protocol has precise validation rules, so not every string beginning xn-- is a valid A-label.
DNS resolution uses ASCII-compatible label handling, while browsers may display Unicode labels for usability. Store and compare origins with URL-aware APIs; do not implement origin checks by visually comparing address-bar screenshots.
Punycode encoding alone is not IDNA validation
Punycode, described in RFC 3492, encodes Unicode code-point sequences into a restricted ASCII form. IDNA adds eligibility, normalization, contextual joining, directionality and length constraints. A string successfully converted by a bare Punycode algorithm may still be invalid as a domain label.
Production software should use an IDNA implementation matching its intended specification and policy instead of treating an arbitrary punycode library as a complete validator. Be explicit about whether a tool performs ToASCII, ToUnicode, preprocessing or just Bootstring conversion.
IDNA2008 establishes property-based validity
RFC 5890 and RFC 5891 define terminology and protocol rules, while RFC 5892 defines derived character-property handling and RFC 5893 addresses right-to-left labels. Validity includes restrictions beyond having well-formed Unicode scalar values.
Certain contextual characters and combinations are disallowed. A general-purpose String.normalize('NFC') call alone cannot decide if a DNS label satisfies IDNA2008. Unicode normalization, context rules and domain-label policy must be evaluated together.
UTS #46 provides compatibility mapping for clients
UTS #46 (Unicode IDNA Compatibility Processing) introduces mappings and validity checks that help align user expectations with IDNA2008. Its current specification describes nontransitional processing as the appropriate general mode and deprecates transitional handling.
Examples involving German sharp s and Greek final sigma illustrate why legacy IDNA2003 behavior and IDNA2008 can differ. A Unicode release or browser version can affect mapping tables. Audit implementation version and options rather than assuming a single timeless conversion.
A valid IDN can still be visually confusable
IDNA is concerned with valid domain-label syntax and interoperability, not exhaustive protection against lookalike hostnames. UTS #39 adds confusable-detection mechanisms, and browsers may apply further script/display heuristics.
Do not label every non-ASCII domain fraudulent. Compare canonicalized origin data and trust attributes, then offer transparent display in security-sensitive flows. A visually similar domain can still have a different registrant and DNS authority.
Labels and URL origins are different scopes
A domain consists of labels separated by dots; a URL origin also includes scheme and port, and host canonicalization is defined by URL processing. Confusing a full URL with a single IDNA label can make validation inconsistent.
Use new URL(input) in a modern browser or equivalent standards-aware URL parser for URL inspection, but understand that parsing success does not certify a website as safe. Credentials, scheme, actual DNS resolution and browser-origin enforcement are separate security questions.
Directionality and join controls require context
Arabic and Hebrew domain labels may invoke IDNA bidi rules. U+200C and U+200D have ContextJ restrictions in the relevant IDNA processes, so arbitrary insertion can make a prospective label invalid even when the same characters are legitimate in ordinary prose.
Do not remove these characters silently and then claim the original domain is valid. Report where validation failed, preserve the submitted Unicode spelling for diagnostics, and use precise Unicode and IDNA versions.
Display should communicate actual navigation targets
A safe application UI shows link destinations in an inspectable way and avoids using only a branded display name as evidence of authority. Browsers may present the Unicode U-label or punycode A-label depending on compatibility and security criteria.
For administrative tools, record the parsed origin, the ASCII hostname and the user-visible form. Handle non-ASCII names sensitively; punycode rendering is not a universal sign of maliciousness, nor does Unicode rendering prove safety.
Test protocol outputs and confusable reviews separately
Include a valid non-ASCII example such as bücher.example, plain ASCII, labels with uppercase mapping, prohibited punctuation, joiner edge cases and bidi labels. Check ToASCII/ToUnicode results against official UTS #46 test data when that algorithm is claimed.
Then separately test UTS #39 confusability and product policy; a strict protocol pass is not a non-spoofability guarantee. When behavior changes across platforms, log IDNA tables, URL parser, locale and Unicode versions.
Reproducible example and scope
This example isolates one specific aspect of text representation, validation or accessible content. It is not a full production security validator or a comprehensive accessibility test: field-specific policy, Unicode data releases, browser behavior and assistive-technology feedback require independent verification.
// WHATWG URL parsing in a browser with IDNA hostname processing:
const u = new URL('https://bücher.example/path');
console.log(u.hostname); // xn--bcher-kva.example in common implementations
console.log(u.origin); // https://xn--bcher-kva.example
// Parsing and punycode output DO NOT prove ownership or security.
// An IDNA validator must separately meet RFC/UTS protocol requirements.Capture the source code points, context, any intentional transformation and observed outcome. Exact Unicode identity, comparison-key equivalence and user comprehension are separate measurements. Preserve the original value when generating derived search, display or inspection forms.
Evidence and interoperability comparison
| Case | Specimen | Interpretation |
|---|---|---|
| U-label | bücher.example | human-readable Unicode label form |
| A-label | xn--bcher-kva.example | ASCII-compatible IDNA label form |
| Punycode | RFC 3492 | encoding mechanism, not whole validity protocol |
| UTS #46 | nontransitional mode | compatibility mapping and checks |
| IDNA2008 | RFC 5890–5893 | eligibility, context and bidi requirements |
| UTS #39 | confusability | independent spoof-risk analysis |
Do not treat a successful string normalization or a valid HTML structure as evidence that every possible attack has been prevented or that every screen reader will pronounce the result correctly. Match each claim to an applicable specification and observable test.
Testing protocol and limitations
- U-label. Build a controlled test of
bücher.example, retaining the actual Unicode scalar sequence and relevant browser, screen-reader or protocol version. Expected interpretation: human-readable Unicode label form. Document both correct behavior and plausible false positives. - A-label. Build a controlled test of
xn--bcher-kva.example, retaining the actual Unicode scalar sequence and relevant browser, screen-reader or protocol version. Expected interpretation: ASCII-compatible IDNA label form. Document both correct behavior and plausible false positives. - Punycode. Build a controlled test of
RFC 3492, retaining the actual Unicode scalar sequence and relevant browser, screen-reader or protocol version. Expected interpretation: encoding mechanism, not whole validity protocol. Document both correct behavior and plausible false positives. - UTS #46. Build a controlled test of
nontransitional mode, retaining the actual Unicode scalar sequence and relevant browser, screen-reader or protocol version. Expected interpretation: compatibility mapping and checks. Document both correct behavior and plausible false positives. - IDNA2008. Build a controlled test of
RFC 5890–5893, retaining the actual Unicode scalar sequence and relevant browser, screen-reader or protocol version. Expected interpretation: eligibility, context and bidi requirements. Document both correct behavior and plausible false positives. - UTS #39. Build a controlled test of
confusability, retaining the actual Unicode scalar sequence and relevant browser, screen-reader or protocol version. Expected interpretation: independent spoof-risk analysis. Document both correct behavior and plausible false positives.
For system-level verification, add adversarial input and legitimate multilingual exceptions. Test both the algorithmic result and the human decision it supports. A high-quality report includes exact Unicode scalars, environment versions, expectations, policy choice and clear error classification.
Interpreting unintended changes
When a result differs, determine whether the change arises during byte decoding, normalization, security classification, rendering, assistive technology or the clipboard. A fix targeting the wrong layer can silently destroy valid language text or leave the original ambiguity unresolved.
Primary standards and implementation documentation
Use the following primary references to verify normative requirements and data-version implications. A Unicode Technical Standard, core Unicode conformance, browser accessibility behavior and application policy are distinct mechanisms with different obligations.
- UTS #46 Unicode IDNA Compatibility Processing — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
- RFC 5890: Definitions — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
- RFC 5891: IDNA Protocol — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
- RFC 5893: Right-to-Left Labels — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
- RFC 3492: Punycode — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
- UTS #39 Unicode Security — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
- WHATWG URL Standard — primary specification or accessibility reference; verify its applicable version and distinguish normative language from implementation-specific recommendations.
Related published research
The Identifiers, Confusables & Security virtual silo connects these technical notes to the broader Unicode interoperability research library. Links below point to other published documents with adjacent concerns.
- unicode homograph attacks
- unicode confusables lookalikes
- unicode identifier security profiles
- right to left text web interfaces
Keep user-facing content independently intelligible, and maintain an explicit distinction between decorative output, its encoded characters and any alternate form supplied for accessibility or security review.