Best Arabic Web Fonts: A 20-Font Measured Performance Guide

Every number in this guide comes from a script that reads the actual installed Fontsource npm packages on disk, not a spec sheet or a vendor's own size claims. For each of 20 Arabic font families it measures the Arabic-subset WOFF2 file at regular (400) and bold (700) weight, checks whether a Latin subset and a variable-weight file also ship, and runs a 7-point coverage test against each font's declared Unicode ranges.

All 20 families passed all 7 coverage checks, every one declares full support for Arabic, Persian, and Urdu script ranges plus digits, diacritics, and punctuation. That's worth stating plainly: for this set, script coverage is not the differentiator. Every family here can render the same Unicode Arabic block content; what actually varies is byte size, and by how much depends heavily on which of the sections below applies to you.

The script is checked into this site's own repository and reproducible with one command: pnpm benchmark:arabic-fonts. Its own documented limitations are worth repeating here rather than glossing over: it measures file size, not network latency, cache behavior, render time, or layout shift, and coverage tests confirm declared Unicode ranges, not shaping quality or language-specific typographic correctness. Readability recommendations later in this guide are editorial judgment, not benchmark output.

Two-weight Arabic size (regular + bold WOFF2) is the baseline column, since it's the minimum most products actually ship. The Latin column shows what the same family costs once you add a matching Latin subset, and the variable column shows the single variable-weight file where one exists.

Tajawal and Reem Kufi anchor the bottom of the table within 100 bytes of each other. Harmattan, at the other end, is nearly 15x Tajawal's size for the same two-weight Arabic job. That range alone is the reason "just pick a popular Arabic font" is bad advice: two families can serve visually similar UI roles and differ by an order of magnitude in delivery cost.

Sort the table above by classification instead of size and a pattern shows up immediately: 7 of the 20 families measured are Naskh, the calligraphic, cursive-joined style built for long-form reading, and 6 of those 7 land in the largest half of the ranking. Only Markazi Text breaks the pattern, sitting at rank 10 of 20.

This isn't a flaw in any individual font. Naskh faces carry far more contextual glyph variants and ligature forms to render joined Arabic script correctly across a paragraph of body text, that's the entire point of the classification, and it costs bytes. Sans and Kufi faces, built for short UI strings rather than paragraphs, get away with a smaller glyph set.

The practical takeaway: if your use case is genuinely long-form reading (articles, documentation, e-books), budget for a Naskh face and accept the size, Markazi Text is the one exception that keeps the reading-appropriate joining behavior at UI-face pricing (45.0KB). If your use case is UI chrome, dashboards, or navigation, a Naskh face is usually the wrong choice on both size and legibility-at-small-sizes grounds, regardless of how it looks in a specimen at 48px.

Of the 20 families measured, 12 ship a variable-weight WOFF2 alongside their static files. The assumption going in is usually that a single variable file beats loading two static weights separately. Measured, that assumption holds for only 5 of the 12:

Noto Sans Arabic, likely the single most commonly reached-for Arabic web font by default, is the worst case in this set: its variable file measures 68% larger than just loading the two static weights most products actually use. A variable axis is only worth its weight when a product genuinely needs a continuous weight range (animated weight transitions, several distinct weights in one view). If you need exactly two weights, check the static two-weight total against the variable file before assuming the variable version is the efficient choice, this table shows it frequently isn't.

With script coverage equal across all 20 and size behaving unevenly across classification and variable-vs-static, the decision comes down to matching classification and weight strategy to what the font actually has to do.

UI, dashboards, forms, navigation

Stay in Sans or Kufi. Tajawal, Cairo, Mada, Vazirmatn, and Noto Sans Arabic cover this role; among them, Tajawal and Reem Kufi are the cheapest starting points, and Noto Sans Arabic is the most expensive by a wide margin once you account for its variable file.

Long-form reading, articles, documentation

Budget for Naskh. Amiri, Noto Naskh Arabic, Markazi Text, Scheherazade New, and Lateef cover this role; Markazi Text is the size-conscious pick among them, the rest cost considerably more but are built for sustained paragraph reading.

Headings and branding

Kufi and Display faces (Reem Kufi, Changa, El Messiri, Noto Kufi Arabic) give geometric or expressive character at a size cost closer to Sans than Naskh, reasonable for a headings-only role where you're not loading body text weight.

Just want the smallest starting point

The 8 smallest measured families are Tajawal, Reem Kufi, Changa, Mada, El Messiri, Alexandria, Cairo, and Rubik, all under 35KB for two weights. Start there, then confirm visual fit before committing.

For a deeper, system-level treatment of Arabic and bilingual web development beyond fonts, direction, forms, and SEO, see the Arabic Web Development guide.

The "+ Latin" column in the ranking table isn't a rounding error. For Tajawal, the Latin subset alone adds 19.8KB on top of a 17.5KB Arabic file, more than doubling the cost. For Noto Sans Arabic, it's a smaller relative jump (+21KB on 96.7KB) but still real weight for characters a primarily-Arabic interface may barely use.

Import only the subset you need

Fontsource ships subsets as separate files specifically so you can import {family}-arabic-{weight}-normal.woff2 without pulling in {family}-latin-{weight}-normal.woff2. If your product is Arabic-primary with only occasional Latin (brand names, numerals in some locales), importing the Latin file for every visitor is pure waste.

Preload only the weight the first paint needs

Two weights measured together is the baseline this guide uses for comparability, but most pages only need regular weight for first paint, with bold loaded for whatever triggers it (headings, emphasis). Preload the regular weight; let bold load on demand.

Set font-display: swap

Arabic text has no fallback font that renders anywhere close to correctly, an unstyled-text flash is far less costly to user experience than a blocked paint waiting on a font file, regardless of which of the 20 families you choose.

Verify the real rendering before shipping

File size tells you delivery cost, not whether the font actually looks right in your layout, at your sizes, mixed with your Latin content. Check the result with the RTL Preview tool before committing to a choice this guide's numbers alone can't make for you.