Trace text from UTF-8 bytes through code points, normalization, grapheme boundaries, bidirectional layout, confusable analysis, and tokenizer-facing forms.
Unicode security is the discipline of preserving and comparing the byte, code-point, grapheme, identifier, logical-order, visual-order, and tokenizer representations of text before making identity, authorization, moderation, or execution decisions.
The submitted report remains byte-identical. This separate review, checked 2026-08-26, narrows implementation claims and gives visitors a decision path before they generalize from a local result.
Output produced deterministically by the local runtime.
Useful model or subset that must not be mistaken for full conformance.
Conclusion that needs an exact implementation, trust system, model, parser, or human review.
| Question | What the local page can answer | What it does not establish | Next evidence step |
|---|---|---|---|
| Are two inputs byte-identical? | Yes — use the exact byte and SHA-256 views. | Whether they are canonically, visually, or semantically equivalent. | Compare normalized copies and apply context-specific policy. |
| Does the input contain selected bidi or invisible controls? | Yes — for the explicitly allowlisted code points. | A complete Unicode security verdict. | Use a full Unicode 17.0 property implementation and language-aware review. |
| Is an identifier safe to register? | No — this page provides evidence only. | Confusable, mixed-script, locale, or account-policy acceptance. | Run a version-pinned UTS #39 profile and high-value-name collision policy. |
Demonstrates why byte, normalization, identifier, and grapheme views must remain separate.
Expected boundary: The original input remains unchanged while bounded diagnostics expose differences and limitations.
Open prepared laboratoryNo single view is automatically authoritative. Preserve the source, identify each parser or receiver, and compare their outputs before authorizing a consequential decision.
Exact UTF-8 octets retained as evidence.
Logical Unicode scalar sequence and selected properties.
A bounded educational cluster count; full UAX #29 conformance requires current Unicode data.
NFC, NFD, NFKC, and NFKD are compared without replacing the original.
Scripts, default ignorables, bidi controls, and confusable skeleton candidates.
Renderer-dependent layout remains distinct from logical order.
The workflow preserves evidence before transformation and keeps structural inspection separate from execution, remote verification, or model behavior.
These controls are contextual. They reduce a defined risk; they do not guarantee safety, truth, attribution, or resistance to every adaptive attack.
Use NFC consistently for selected storage/comparison contexts, not as an indiscriminate rewrite.
Wrap untrusted directional text in isolates and visibly flag override controls.
Use current UTS #39 data for high-value identifiers and review mixed scripts contextually.
Truncate at grapheme boundaries and validate after concatenation.
Test the exact tokenizer and parser versions used by the application.
Definitions are linked into the site-wide glossary and back to the full report.
Distinct Unicode sequences that represent the same abstract character under canonical normalization.
NFKC or NFKD processing that folds compatibility distinctions and can be intentionally lossy.
A user-perceived character that may contain multiple Unicode code points.
A standardized prototype mapping used to compare visually confusable identifiers.
A code point normally omitted from rendering when unsupported, while remaining present in the logical text.
The stored code-point order consumed by parsers, compilers, and tokenizers.
The glyph order produced after bidirectional resolution and shaping.
An identifier combining characters from multiple scripts, requiring contextual policy review.
These links are provided for visitors who want the governing specification, paper, framework, or implementation documentation. Links open in a new tab; the site does not fetch them during runtime analysis.
Normative definitions of NFC, NFD, NFKC, and NFKD.
Normative or first-party specification material.Logical-to-visual reordering, embeddings, overrides, and isolates.
Normative or first-party specification material.Identifier restrictions, mixed-script analysis, and confusable skeletons.
Normative or first-party specification material.Grapheme, word, and sentence boundary algorithms.
Normative or first-party specification material.Unicode-aware regular-expression requirements.
Normative or first-party specification material.Peer-reviewed study of bidi-based source-code display differentials.
Original research or formal conference publication.Security background and spoofing considerations.
First-party guidance, framework, registry, or standards-program material.The full submitted report is preserved byte-for-byte in the governed research library and in durable repository documentation. The laboratory turns selected concepts into deterministic local output without external calls or hidden persistence.
A deep treatment of Unicode bytes, scalar values, normalization, grapheme segmentation, default ignorables, bidirectional controls, confusable skeletons, identifiers, tokenization, and internationalization-safe defenses.
Read governed reportCompare raw UTF-8, code points, an explicitly approximate grapheme view, four bounded normalization copies, scripts, bidi controls, selected default ignorables, and an educational confusable skeleton without overwriting the original.
Open bounded laboratory