Arabic engineering reference
Arabic Unicode Ranges: Blocks, Regex and Font Subsets
Arabic text spans several Unicode blocks, while Arabic-script matching and font coverage require more than a single block range. This reference distinguishes core letters, extension blocks, and compatibility presentation forms, then shows how to choose regex properties and font subsets without confusing character coverage with successful shaping or language validation.
Block boundaries and purpose
Bounds are inclusive. A block is an allocation range, not a list of allowed characters for your application. Some positions may be unassigned; digits, punctuation and marks are not interchangeable with letters.
| Block | Inclusive U+ range | Purpose |
|---|---|---|
| Arabic | 0600–06FF | Core letters, digits, punctuation and marks |
| Arabic Supplement | 0750–077F | Additional letters for Arabic-script languages |
| Arabic Extended-B | 0870–089F | Additional letters and annotation signs |
| Arabic Extended-A | 08A0–08FF | Additional letters and combining signs |
| Arabic Extended-C | 10EC0–10EFF | Further extended letters and marks; supplementary plane |
| Arabic Presentation Forms-A | FB50–FDFF | Compatibility forms and ligatures |
| Arabic Presentation Forms-B | FE70–FEFF | Compatibility contextual forms and related characters |
Match the script, then apply your input policy
Script_Extensions=Arabic is useful for discovering Arabic-associated characters, including shared characters whose primary Script can differ. It is not an Arabic-language validator: Arabic script also serves other languages. Spaces, Latin identifiers and punctuation need separate decisions.
const hasArabicScript = /\p{Script_Extensions=Arabic}/u;
const coreBlockOnly = /[\u0600-\u06FF]/u;
// Detection is not validation: these tests answer different questions.
console.log(hasArabicScript.test("\u0627"));Subset from your actual content
Guidance: collect the characters your product serves, include punctuation, marks and required language extensions, and preserve the font’s shaping layout tables when subsetting. A CSS unicode-range declaration controls eligibility to download a font; it does not add missing glyphs.
A font covering the core Arabic block does not thereby cover Persian, Urdu, all Quranic annotation or extension blocks. Conversely, a broad block declaration does not demonstrate actual glyph coverage. Test words and combining sequences with the real font, weights and browser.
Compatibility forms are a migration concern
Use ordinary letters for new text and let the shaping engine select glyphs. Do not require Presentation Forms-A/B merely to display ordinary joining Arabic. Their presence in legacy input is a migration issue, not evidence that every new font subset needs those blocks.
Guidance: inspect compatibility normalization on a copy of legacy text and retain the original. Avoid silently rewriting user identifiers. Unicode’s Arabic chapter distinguishes encoded compatibility forms from contextual shaping performed by rendering rules.
Related references and tools
- Arabic Digits: Unicode and JavaScript Reference
- Arabic Tashkeel: Diacritics and Removal Regex
- Arabic Letter Forms: 28 Letters and Joining Rules
- Arabic Language Codes: lang, dir and hreflang
- Arabic Numeral Converter
- Arabic Text Normalizer
- Arabic Regex Patterns
- Arabic Search Normalization
- What lang="ar" and dir="rtl" each do
Questions and answers
Is U+0600–U+06FF enough to validate Arabic?
No. It is a block boundary containing different character types, while Arabic script extends into other blocks and is also used by languages beyond Arabic.
Do fonts need presentation-form characters to join letters?
Ordinary Arabic letters should be shaped by the rendering engine. Unicode recommends base characters for interchange rather than encoding contextual presentation forms as new text.