Unicode character properties turn an unfamiliar string into structured data: you can identify letters, marks, numbers, scripts, directionality, and case behavior instead of relying on visual appearance alone. This lookup guide explains the properties developers use most often, how to apply them in validation and text analysis, and how to keep Unicode-aware code current as the Unicode Standard evolves.
Overview
A Unicode code point is an abstract character value, but the value itself does not tell you everything an application may need to know. Unicode character properties add useful classifications and behavior. A search feature might need to recognize letters across many writing systems; a form validator might need to distinguish decimal digits from other numeric symbols; a renderer or text-processing pipeline may need to account for combining marks and bidirectional text.
The most commonly used property is General_Category. Its broad groups include letters (L), marks (M), numbers (N), punctuation (P), symbols (S), separators (Z), controls and formatting characters (C), and unassigned code points (Cn). More specific values include Lu for uppercase letters, Ll for lowercase letters, Nd for decimal digits, and Mn for nonspacing marks. These categories are useful for filtering and analysis, but they are not a complete substitute for language-aware rules.
Scripts describe writing systems associated with characters, such as Latin, Greek, Cyrillic, Arabic, or Han. A character may have a Script property indicating its primary script, while Script_Extensions can indicate that it is used with more than one script. Script detection is therefore best treated as a classification aid, not as a definitive statement about the language of an entire string.
Blocks are contiguous ranges of code points named for organizational convenience. A block can help you locate characters in a reference or build a diagnostic display, but block membership does not necessarily mean that every character in the range belongs to one script or serves one purpose. For a practical range lookup, see Unicode Block Reference: Find Characters by Range and Script.
Other important properties include Bidirectional_Class, which supplies directional behavior used by bidirectional text algorithms; numeric properties, which distinguish decimal, digit, and other numeric values; and case properties, which describe uppercase, lowercase, titlecase, case folding, and related behavior. A character can look like a letter or number while having behavior that differs from an ASCII equivalent, so property-aware processing is safer than testing only visible glyphs.
When investigating one character, record at least its code point, name, General_Category, script information, and any relevant decomposition or case data. An online lookup can make this inspection quick; the guide to finding Unicode characters, code points, and UTF-8 bytes is useful when the input is difficult to identify.
Maintenance cycle
Unicode data is versioned, and software libraries do not all adopt new versions at the same time. Treat property tables, regular expressions, validation rules, and generated reports as maintained technical assets rather than permanent constants.
On a scheduled review cycle, check the Unicode version supported by each runtime, database, regular-expression engine, and text library in your stack. Then compare it with the version assumed by your application or test fixtures. The goal is not to update blindly; it is to know whether a version change could affect classification, case conversion, normalization, sorting, identifier checks, or display.
Keep a small representative test corpus. Include characters from the scripts your product supports, letters with case mappings, combining sequences, decimal digits from more than one writing system, directional text, emoji sequences if relevant, and deliberately malformed input. Store expected properties or expected application behavior with the corpus. This makes a library upgrade reviewable and helps distinguish a genuine regression from a changed Unicode data set.
Separate stable application intent from implementation details. For example, “accept a user’s display name without rejecting valid scripts” is a product requirement; “allow characters matching one particular regular-expression category” is an implementation choice. When the latter changes, tests should reveal whether the former still holds.
For normalization-specific behavior, pair property checks with a review of NFC, NFD, NFKC, and NFKD normalization. Properties describe characters, while normalization changes the representation of equivalent or compatibility-related text. These are related concerns, but they should not be conflated.
Signals that require updates
Several practical signals indicate that a Unicode property reference or implementation deserves attention:
- A runtime or dependency changes its Unicode data version. Re-run property and normalization tests rather than assuming identical results.
- A new language, script, or user group is added. Review script detection, allowed-character rules, case handling, input methods, and font coverage.
- Validation rejects text that users consider valid. Capture the exact code points, not only a screenshot, and inspect General_Category, Script_Extensions, normalization, and invisible marks.
- Search, sorting, or identifiers behave inconsistently. Check case folding, combining sequences, confusables, punctuation, and locale-sensitive requirements.
- Security or abuse patterns change. Review mixed-script input, bidirectional controls, invisible formatting characters, and confusable characters. The Unicode confusables checker guide provides a useful diagnostic starting point.
- Search intent shifts toward a specific implementation. Refresh examples for the languages and engines readers actually use, while retaining the property definitions that remain broadly applicable.
Do not treat a change in a property table as automatically harmful. New assignments or improved library support may be beneficial, but they can expose assumptions in hard-coded allowlists, database constraints, or client-side validation.
Common issues
Confusing blocks with scripts. A block is a range; a script is a usage classification. Use Script or Script_Extensions for script-oriented logic and blocks mainly for navigation, diagnostics, or range-based tooling.
Treating General_Category as a language validator. A rule such as “allow letters and marks” may be a reasonable starting point for a display-name field, but it cannot determine whether text is a valid word, a permitted language, or a safe identifier. Apply product and locale rules separately.
Counting code points as characters. A visible grapheme cluster can contain a base character, combining marks, joiners, variation selectors, or other components. String length, cursor movement, truncation, and deletion should use an appropriate grapheme-aware mechanism when user-perceived characters matter. See the related Unicode encoding errors debugging checklist when symptoms appear during transport or rendering.
Assuming every number is an ASCII digit. Numeric characters have different properties and values. Decide whether an input needs ASCII syntax, decimal digits from supported scripts, or general numeric semantics. Convert only after the accepted scope is explicit.
Ignoring bidirectional controls. Directional behavior is not visible in source text in the same way as ordinary letters. Log code points during investigations, preserve directionality where required, and test mixed-direction strings in interfaces, logs, and generated documents.
Using case conversion as normalization. Uppercasing, lowercasing, and case folding serve different purposes and can be locale-sensitive. Choose the operation according to whether you are displaying text, comparing values, or generating an identifier.
When to revisit
Revisit this reference at least on a planned maintenance cycle, and immediately when your Unicode-aware dependency, runtime, database, or regular-expression engine changes. Also review it before adding script support, changing identifier policy, redesigning search, or investigating unexplained text-validation failures.
A practical update checklist is:
- Record the Unicode data versions used in production, development, and test environments.
- Run a corpus containing letters, marks, numbers, scripts, combining sequences, directional text, and edge cases from real reports.
- Compare code-point properties and application outcomes before and after a dependency update.
- Inspect hard-coded ranges, allowlists, regex property escapes, and database constraints for outdated assumptions.
- Refresh examples and lookup links when reader questions or implementation targets change.
- Document any intentional compatibility limits, such as an ASCII-only protocol field or a restricted identifier policy.
For release preparation, combine this property review with a broader Unicode text QA checklist and API validation checks. Keeping the reference, tests, and implementation notes aligned gives developers a dependable way to diagnose text behavior without mistaking appearance, byte encoding, blocks, or normalization for the full Unicode model.
