Why Arabic text needs different line heights

The English paragraph looks calm at the approved line height. Switch to Arabic and the lines seem to lean into one another. A mark below one line nearly meets a mark above the next. Someone proposes shrinking the font. The font, having committed no crime, is about to take the punishment.

Arabic text can need a different line height from the Latin text beside it because the selected typeface and the content use vertical space differently. Arabic letters have ascenders and descenders, and vowel marks can appear above or below them. A font's metrics influence where those shapes sit around the baseline. The result is not a universal “Arabic requires 1.8” rule. It is a reason to test the actual font and content before reusing a Latin typography token.

This guide is about vertical rhythm: what line-height controls, how to choose a value per language, and how to tell crowding from clipping. If the whole box is too narrow or a line is hidden by overflow, that is a related layout problem, but changing line height alone cannot create missing width.

What line-height controls#

In a horizontal writing mode, line-height helps determine the height of each line box. The browser places glyphs and inline elements on baselines within those boxes. If a paragraph wraps to three lines, the line boxes establish the vertical distance through which the reader moves. MDN's line-height reference describes the property in those terms.

line-height is not the height of the paragraph. It is not the painted height of a particular Arabic letter, either. A line may contain glyphs from several fonts, an emphasized word with a different size, or an inline icon. Those participants can affect the line box. The CSS visual formatting model explains how inline boxes, font metrics and vertical alignment contribute to line height.

The other distinction is between crowding and clipping. With little space between baselines, adjacent lines can look crowded or even let painted glyphs intrude on one another. That does not automatically mean a glyph has been cut off. For text to disappear at a box edge, look for a fixed block size, a clipping overflow rule or another paint boundary. Raising line-height inside a fixed-height clipped card may push the final line farther out of sight. It is an excellent way to turn one hidden line into two.

Test the actual symptom. If the marks are visible but hard to distinguish from the neighboring line, adjust line spacing. If marks vanish at a straight boundary, inspect the boundary as well. If the text overlaps another component, investigate that component's layout before assigning all blame to the font.

Why Arabic may need a different value#

Arabic script is not a Latin font rearranged from right to left. Letter forms join, rise, descend and combine with marks in ways that depend on the word and the typeface. More than one diacritic can attach to a base character; font positioning determines how those marks sit. The W3C Arabic and Persian layout requirements documents these typographic features.

The word may matters. A short unvowelled interface label and a fully vowelled reading passage do not exercise the same vertical shapes. Two Arabic fonts may reserve different space above and below the baseline. A typeface used at body size may look comfortable with one line height and need another at a large display size. The correct value belongs to the combination of font, size, weight, content and context.

Latin text is not exempt from these questions. Accents, different faces and mixed-size inline content can also demand room. The useful engineering conclusion is narrower: a line-height value chosen by looking only at English does not prove that Arabic lines will read clearly. Nor does one Arabic screenshot prove that every text style is covered.

This is particularly visible in a children's reading passage. Such content can include marks that ordinary navigation labels omit. A design reviewed only with an unmarked menu label has missed the very shapes the reading view exists to teach. That would be awkward, though at least the syllabus would be short.

A reading passage with cramped lines#

Consider a reading app that presents a short, vowelled passage. The text is original sample content for the component; it is not a quotation from a published work.

<section class="reader" lang="ar" dir="rtl">
  <p class="reader__passage">
    قَرَأَتْ هِنْدٌ كِتَابًا فِي الْحَدِيقَةِ.
    ثُمَّ عَادَتْ إِلَى الْبَيْتِ.
  </p>
</section>

The passage needs to wrap naturally at the reading pane's width. Suppose the English version was designed with this rule:

Problem

.reader__passage {
  font-size: 1.125rem;
  line-height: 1.5;
  max-inline-size: 32rem;
}

1.5 is a reasonable starting point for body text, not a guarantee for the Arabic font in this pane. If its marked lines feel crowded at the actual reading width, copying the English token without testing has left the decision unfinished. Nothing about dir="rtl" changes the numerical line height; direction controls reading and layout orientation, not the amount of vertical space allocated between these lines.

Better, after checking the rendered passage

.reader__passage {
  font-size: 1.125rem;
  line-height: 1.5;
  max-inline-size: 32rem;
}

:lang(ar) .reader__passage {
  line-height: 1.7;
}

The English styling is unchanged. The Arabic passage receives more space between lines. 1.7 is an example of a value selected after inspection, not a published target for every Arabic page. Test it with the intended font, on two or more lines, at the real pane width. If the passage's lower marks still approach the next line, adjust the value. If the gap becomes so large that the lines no longer read as one paragraph, back it down. Typography is a visual decision with a technical cause, not a contest to find the largest multiplier.

In the snippet, :lang(ar) matches elements whose determined language is Arabic, including descendants that inherit lang="ar" from the section. You can put lang="ar" on the document's root when the whole page is Arabic. For a mixed-language page, mark the Arabic region itself. The selector can then follow the content rather than the route name.

Why 1.5 is a signal, not a certificate#

MDN recommends a minimum line-height of 1.5 for main paragraph content as an accessibility starting point. The number is useful. It is also easy to misuse. A paragraph at 1.5 can still look crowded with a particular font and marked content; a heading below 1.5 is not automatically broken. Those are different contexts.

Ritla's R052 reports Arabic body text with a line-height below 1.5. It does not assert that lines at 1.5 are visually comfortable, that all diacritics are visible, or that every control must use that same ratio. Keep the scope of the check in mind when triaging it. A flagged body paragraph deserves a closer look; an unflagged one still deserves a reading test.

There is a second reason to avoid treating 1.5 as a one-time stamp. The W3C text spacing criterion asks that content and functionality remain available when users increase line spacing and other text spacing properties. That is a layout resilience test. It does not prescribe a single Arabic font metric or say that author CSS at exactly 1.5 solves every typography issue.

Try the reading passage with increased spacing, then inspect its parent. A paragraph allowed to grow will usually make room; a fixed-height pane with overflow: hidden may cut off the final line. The line-height value can be correct for reading while the container is still wrong. Keep both findings.

Select by language, not by direction#

Many sites style Arabic through [dir="rtl"]. That works only if direction and language happen to coincide everywhere the rule applies. They do not have the same meaning. A Hebrew page is RTL but does not use Arabic script. An Arabic paragraph can sit within an LTR document. A Latin product code inside an Arabic page may not need the Arabic paragraph's typographic treatment.

Use :lang(ar) for a rule that exists because the content is Arabic. Use dir and logical CSS properties for rules that exist because the layout flows from right to left. The HTML lang reference explains how language is determined and inherited; the guide to dir="rtl" covers direction as a separate concern.

This distinction also keeps a bilingual passage honest. The Arabic text can inherit the Arabic line-height token while an English citation in a separately marked element can receive its own language styling. A single inline Latin phrase does not necessarily demand a different line box, however. Apply an override where a component or paragraph needs it, then inspect mixed lines rather than sprinkling line-height on every span.

If the site has several Arabic locales, :lang(ar) matches language tags with Arabic as their primary language, such as regional variants. That is useful when the same typeface and content treatment apply. If one locale uses a distinct typeface or writing style, make the selector more specific and test the resulting font, rather than pretending all Arabic locales share identical metrics.

Use a unitless line height when it should scale#

For paragraphs and inherited typography, unitless line-height values are often the least surprising choice. A value of 1.7 is multiplied by the element's own font size. If a nested run becomes larger, it inherits the factor and calculates its own used line height. MDN recommends unitless values for this inheritance behavior in its line-height documentation.

Compare a length specified on the parent:

.reader__passage {
  font-size: 18px;
  line-height: 27px;
}

.reader__emphasis {
  font-size: 24px;
}

The emphasized span inherits the parent's computed 27px line height unless another rule changes it. With a unitless parent value of 1.5, the span's own 24px font size produces a 36px used line height. That is a more useful relationship when the larger run is intentional. The example is about CSS inheritance, not a recommendation to enlarge a random word in a children's passage.

em and percentage line heights can also resolve to an absolute computed length before inheritance. They may therefore preserve a line box measured for the parent while a child uses a larger font. A unitless token travels as a ratio. You can still set an explicit length when you truly need a fixed typographic grid, but then the font and all inline variations need to be tested against it. A grid is not a reason to crop the content that refuses to fit its cells.

Do not conflate line-height: normal with a stable design token. The browser chooses a value influenced by its font handling, and the result can change when a fallback font paints the Arabic glyphs. If the reading view relies on a particular rhythm, specify and test it.

Font fallback can change the spacing question#

A CSS declaration names a font stack. It does not prove that the first named font painted every Arabic character. If the requested webfont fails to load or lacks a glyph, the browser may use another face for the Arabic text. That face can have different ascent, descent and mark placement. W3C's font fallback guidance explains why mixed-font rendering deserves attention.

Inspect rendered fonts in DevTools for the actual Arabic passage. The computed font-family property tells you what was requested; the rendered-font view tells you what supplied the glyphs. R050 reports Arabic text that falls back past the declared family, including a webfont that failed to load. Treat the report as a font issue first. Widening line-height can make fallback text look less cramped, but it does not restore a missing font or missing glyph coverage.

Test after fonts load and once with the webfont unavailable. If the fallback is part of what users may see, it needs enough line room too. If it is a momentary loading state, inspect whether the passage jumps or clips while the font changes. The answer may involve the chosen fallback face, container size and line height together. One CSS value cannot promise identical ink geometry for two different fonts.

Different styles of the same family also matter. Bold, medium and regular weights can use distinct outlines and metrics, and an italic or oblique treatment may not be suitable for Arabic body text. Keep the test on the actual weight shown in the reading pane. Do not sign off on regular text and assume a bold highlighted sentence has been covered by association.

Line height cannot repair a box that refuses to grow#

Suppose the passage looks better at 1.7, but the final line disappears inside a fixed-height lesson panel. That is not evidence that the larger line height was wrong. The panel has a separate size constraint. Inspect height or block-size and the computed overflow on the panel and its ancestors.

For content that should remain visible, prefer a minimum block size over a fixed one:

.reader__panel {
  min-block-size: 12rem;
  padding-block: 1rem;
}

The panel keeps a baseline size and can grow as text gains lines. If a specific view needs a bounded region, provide deliberate internal scrolling and make sure the whole passage is reachable. Merely setting overflow: hidden is a disappearance policy, even if the design review called it tidying.

The MDN overflow reference describes how content is clipped or scrolled once it exceeds a box. A tighter line-height may pull the final line back inside the old box, but it can make the body harder to read. Resize the container according to the content's job. For an excerpt, intentional truncation may be acceptable when the full text is available through an explicit detail view. For a reading exercise, the last line is part of the exercise.

If the lines visibly overlap even with a growing panel, inspect nested inline content and computed typography. A span with a larger font-size, a raised annotation or an inline image can change the line's geometry. Raising the paragraph ratio blindly may help, but identifying the item that stretches or crosses the line box produces a better fix.

Keep line spacing separate from paragraph spacing#

Line height sets the distance through a wrapped paragraph. Margins between paragraphs set a different distance: where one thought ends and another begins. If the reading pane has several paragraphs, you need to inspect both. Increasing margin-block-end gives the next paragraph more room but does nothing for two lines inside the same paragraph. Increasing line-height can make those lines readable yet leave the boundary between paragraphs hard to see.

That distinction is easy to miss when a mockup contains only one paragraph. Test two adjacent paragraphs with the actual Arabic font and content. The last line of the first should not look like the first line of the second, and neither paragraph should collide with a heading or action. Choose paragraph spacing to show the content hierarchy, then keep the line-height decision about the lines within each paragraph.

A fixed block size can defeat both choices. More margin or line height increases the space the text needs. If the pane still insists on its old height, the later lines or the next paragraph may vanish behind an overflow clip. Inspect the container after each spacing change. A design token is not a permission slip for content to extend beyond the box.

This also matters for user overrides. The W3C text-spacing criterion tests increased line and paragraph spacing together. A page should survive that combination, rather than passing when either value changes alone and failing when a reader uses both. Give the container enough freedom to grow and verify that controls after the text remain reachable.

Do not shrink the font to rescue a fixed panel#

Reducing font-size may pull a line back inside a panel, but it changes more than the distance between lines. Glyphs become smaller, line breaks change, and a different number of words may fit across each row. The apparent improvement may come from making the content harder to read. This is especially perverse in a reading app, where reading is the advertised activity.

Before touching font size, hold it constant and adjust the line-height ratio. Let the containing panel grow, then test whether the space between baselines is comfortable with marked words. If the passage is still difficult to read, evaluate the typeface and size as their own decisions. The correct font size for the intended audience is not whatever happens to fit the oldest card dimensions.

The reverse shortcut also fails: increasing line-height to compensate for an unsuitable Arabic font can hide the underlying font choice. Inspect which face actually rendered and how its forms look at the intended size. Spacing can separate lines; it cannot repair glyphs that are too small or missing.

Body, headings and controls need separate tests#

The reading passage is body text. Its line-height decision should not be copied onto every Arabic element. A large heading may be one line with fewer marks and different visual spacing. A button needs enough height for its label and focus ring, but a two-line button may need padding and a different layout as much as a different line-height. A badge that must stay small may need an approved shorter label rather than a microscopic font.

Start with the type roles your product actually has: body, heading, action, caption and data value. For each, note the Arabic font, size, weight, typical content and maximum number of lines. Choose a line-height that works for that role. The ratios may differ because the rendered shapes and tasks differ. Naming the roles is useful; inventing a grand “global multilingual vertical-rhythm architecture” is optional, and I would take the afternoon off instead.

For a control, test the label at its narrowest width and largest supported text size. If it wraps, let the block grow and retain padding around both lines. For a heading, test the longest translated version and any marked words. For body copy, test at least two adjacent lines so you can judge the space between them. A single-line screenshot cannot validate multi-line rhythm, however confident it looks.

Arabic script also should not be squeezed horizontally to compensate for a vertical layout. Tracking changes the space between characters and can disturb connected letters; R051 reports letter spacing applied to Arabic text. The MDN letter-spacing reference notes the concern. If the larger line height makes a panel taller, solve the panel layout rather than trying to make the Arabic word narrower by separating its letters.

Test the decision as a component, not a number#

The best test starts with the exact text and font that created the question. For the reading pane, use the vowelled passage and a longer passage that wraps over several lines. Record the font face, weight and width. Then compare the English and Arabic views while changing only the language-specific rule.

A short pass covers the failure modes:

1. At the intended width, inspect the space between consecutive Arabic lines. Can you distinguish marks belonging to each line without searching for the baseline?
2. Resize until the paragraph gains another line. Check that the panel expands and no line overlaps the next control.
3. Increase browser zoom and text size. Recheck both the line spacing and the panel boundary.
4. Test a word with marks above and below, in regular and bold if the product uses both.
5. Disable the webfont once and inspect the fallback face.
6. Verify the English page remains at its original line height and layout.

DevTools can confirm the winning rule. Select the paragraph and inspect computed font-size, line-height, font-family and the rendered font. For a unitless line height, compare the ratio you set with the element's own font size. If the computed style says the expected value but the page still looks crowded, inspect the actual font and inline children. CSS has answered the question you asked it; you may need to ask a better one.

The W3C text-spacing test is a useful extra stress case: increase line spacing and ensure no content or action becomes unavailable. That catches rigid panels that pass at the author's preferred value and fail as soon as a reader adjusts the text. It is a layout test as much as a typography test.

Choose the spacing the text can use#

Arabic does not come with one mandatory line-height multiplier. It comes with glyphs, marks and fonts that must have room in the component that displays them. Start with a readable body-text ratio, inspect real Arabic at the font and width you ship, then set a language-specific value where the English one leaves lines crowded. Keep the containing box free to grow.

A free Ritla scan can flag Arabic body text with a line-height below 1.5 and Arabic text that falls back past the declared font family. Use those findings to inspect the rendered passage and its container. For the CSS relationships around that typography, continue with the RTL CSS guide. The number in the stylesheet is only finished when the reader can follow one line to the next without the marks attempting a reunion.