Arabic text overflow: causes and fixes

Your English catalog result fits. The Arabic title disappears halfway through, the action button sits on top of it, or the page gains a horizontal scrollbar. Making the font smaller might hide the symptom. It also makes the text smaller, which is a rather literal solution to a layout problem.

Arabic text overflow has several causes that look similar in a screenshot: a box with a fixed size, a flex item that refuses to shrink, a nowrap inherited from a toolbar, a long token with no break point, or glyphs clipped by a tight line box. The fix depends on which limit the text reached. Arabic translations are not always longer than English, and Arabic glyphs are not always taller. Real strings and the selected font decide. The CSS still has to make room when they are.

This guide starts with the visible failure and works back to the rule that caused it. The examples use an archive catalog result with a long title, a collection label and an action. It is the sort of interface where hiding half a title can turn two different records into the same mysterious entry.

First, identify what actually overflowed#

“The text overflows” can describe four different events. Before editing CSS, locate the edge that the content crossed.

These are leads, not diagnoses. A single title can cross its own box and the page boundary. An intentionally scrollable archive table can also have a horizontal scrollbar without being broken. Find the smallest box that fails first; the document is often only reporting its child's problem.

In DevTools, inspect the title, then its parent, then the row or card. Look at the computed values of inline-size or width, min-inline-size or min-width, block-size or height, overflow, white-space, line-height, and the layout mode. If the title is inside flex or grid, inspect the track or flex item that owns the available space. The declared width: 100% on the text itself is not reassuring when its parent already exceeds the viewport.

For a quick lead, compare an element's scroll area with its visible box:

const title = document.querySelector(".record__title");
console.log({
  inlineOverflow: title.scrollWidth > title.clientWidth,
  blockOverflow: title.scrollHeight > title.clientHeight,
});

This works only when .record__title exists on the page being tested. A true result says the content exceeds the element's client box; whether it is visible or clipped depends on overflow. A false result does not clear every typography problem either. Ink from a glyph can be visibly clipped at a tight line edge without a useful change in those box measurements. Keep the visual inspection.

A catalog record with too many constraints#

Here is the archive result. The Arabic strings are the content to test, not filler chosen to fit a demonstration.

<article class="record" lang="ar" dir="rtl">
  <div class="record__copy">
    <p class="record__collection">مجموعة الخرائط الزراعية</p>
    <h2 class="record__title">خرائط توزيع مياه الري في قرى الساحل الشرقي</h2>
  </div>
  <button class="record__action" type="button">عرض تفاصيل السجل</button>
</article>

The catalog designer wants the title beside the action on a wide screen. The following rules seem to achieve that with a short English title:

Problem

.record {
  box-sizing: border-box;
  display: flex;
  gap: 0.75rem;
  inline-size: 26rem;
  block-size: 6rem;
  padding: 0.75rem;
  overflow: hidden;
}

.record__copy { white-space: nowrap; }
.record__action { flex: none; }

There are three separate constraints here. The card is 26rem wide even if its parent is narrower. It is always 6rem tall even if the title needs another line. And the copy is forbidden to wrap at spaces. overflow: hidden then conceals the evidence. A short LTR title may make the arrangement look settled, but the rule is really “content may occupy this exact rectangle.” The content never agreed.

Better

.record {
  box-sizing: border-box;
  display: flex;
  flex-wrap: wrap;
  gap: 0.75rem;
  inline-size: min(26rem, 100%);
  min-block-size: 6rem;
  padding: 0.75rem;
}

.record__copy {
  flex: 1 1 12rem;
  min-inline-size: 0;
  white-space: normal;
}

.record__action { flex: none; align-self: start; }

At the original width, a short English title and the action still sit beside each other in the same order. The record keeps its minimum height. When space is scarce, the box can become narrower, the title can wrap, the card can grow, and the action can move to the next flex line. min-inline-size: 0 lets the copy item shrink within its allotted space. None of those rules guarantees that every archive entry will fit, so test the longest plausible title and the narrowest container where this component appears.

Do not replace the title with an ellipsis simply because the improved layout is taller. If people distinguish records by the later words in the title, truncation changes the task they can perform. Layout should serve the content before the content is asked to disappear politely.

Character counts are a poor width budget#

A translation field may have the same number of characters as its English source and still occupy a different width. Character count does not measure glyph advance, shaping, font weight, punctuation or where a line can break. It also says nothing about the space taken by the button next to the text. A limit such as “titles must be under 40 characters” can be useful for editorial consistency, but it is not a layout guarantee.

Measure the rendered component with the font you intend to ship. For the archive record, test the complete title beside the action, then narrow the parent until the layout stacks. Note the width where it fails, not the length of the string where it happened to fail. A later font update can change that width without changing one character of the translation.

If the product imposes a genuine length limit, make sure it serves the product. An archive may need the full formal document title, while a compact navigation item may have an approved short label. Ask for the short label as a separate translation where one is needed. Slicing a full title in code at a fixed number of characters is not the same as editing it. It can leave the distinguishing words behind and may cut through a sequence the renderer treats as one displayed unit.

Fixed widths fail in two different ways#

A fixed width can constrain the text box itself, or it can make the surrounding layout wider than its parent. Those are related failures, but the remedy differs.

If the title's box is too narrow while the card still has free space, look at the track allocation. A fixed action column, an oversized gap or an inflexible sibling may be taking room that the title needs. Reduce the reserved space or allow the layout to stack. If the whole card is wider than its parent, make its inline size respond to the containing block, as the catalog example does with min(26rem, 100%).

Ritla's R043 reports a fixed-pixel-width container whose Arabic text exceeds the space. It is a specific failure, not a general verdict on every use of px. A small icon can have a fixed size. A data cell that contains a translated sentence needs a different arrangement.

Beware of max-width: 100% as a complete answer. It can stop a box from becoming wider than its parent, but it cannot give a narrow text track more space if the adjacent controls still demand their original width. Follow the width budget: parent content width, padding, gaps, siblings, then text. The arithmetic is dull. That is one of its better qualities.

Box sizing matters too. With box-sizing: content-box, a declared width excludes padding and borders. A 100% wide child plus inline padding can exceed its parent. box-sizing: border-box includes those additions inside the declared size. This is ordinary CSS behavior, not an Arabic exception; Arabic content is simply a reliable witness when the spare space runs out. The MDN box sizing reference documents the difference.

min-width: auto can defeat a flexible layout#

The catalog card may still overflow after you remove its fixed width. Flex and grid items have automatic minimum sizes. Their content can keep a supposedly flexible item from shrinking as far as you expected. MDN's min-width reference describes how an auto minimum for flex and grid items may be based on their content.

This becomes visible when a title contains a long word, a filename or a white-space: nowrap rule. The flex item says it can shrink; its minimum size says it cannot. Both declarations are in the stylesheet, which is why this bug has an irritating air of cooperation.

Put the shrink permission on the item that contains the text:

.record__copy {
  min-inline-size: 0;
}

For a grid layout, the track itself may also need permission to shrink:

.record {
  display: grid;
  grid-template-columns: minmax(0, 1fr) auto;
}

minmax(0, 1fr) sets zero as the flexible track's lower bound. It does not magically create break points inside an unbroken string. If the child text still cannot wrap, it can spill beyond its newly smaller track. Solve the track constraint and the text break policy separately. The CSS Grid specification describes track sizing and automatic minimums; the flexbox specification covers the corresponding flex item behavior.

An edge case matters here: a scrollable code sample or a control with a necessary minimum width may be supposed to resist shrinking. Give such content a local scrolling or stacking strategy rather than applying min-inline-size: 0 to everything on the page. Global cures are especially attractive when you have not yet met their side effects.

If the text overlaps a control but its own box reports no overflow, inspect positioning. An absolutely positioned badge or button no longer reserves space in normal flow, so the title can legitimately fill the area underneath it. Give the text appropriate padding on the control's side, put both items in flex or grid, or change the layout at a narrow width. Increasing z-index only decides which one hides the other. It does not create room for either.

Check whether wrapping was disabled upstream#

Arabic normally has opportunities to break between words. The W3C Arabic and Persian layout requirements describe wrapping Arabic text to the next line between words when it does not fit. A long Arabic sentence overflowing in one rigid line is therefore a reason to inspect CSS, particularly inherited white-space: nowrap.

white-space is inherited. A parent toolbar may set nowrap for short status pills, and a later translation turns one child into a sentence. The child has done nothing unusual. It inherited the wrong promise.

Give the sentence its own wrapping rule:

.record__title {
  white-space: normal;
}

If the source text intentionally contains line breaks, pre-wrap may be appropriate instead. Do not use it reflexively: unlike normal, it preserves spaces and source line breaks, which can make content entered by users look quite different. MDN's white-space reference sets out those behaviors.

Then check the available line width. Enabling wrap cannot help if the text box is only wide enough for a few glyphs, or if another element is absolutely positioned on top of it. The line may wrap correctly into fifteen very short lines and still be unusable. CSS has technically obeyed you. It occasionally enjoys doing that.

Long tokens need a separate break policy#

An archive record may include a filename such as east-bank-irrigation-survey-master-scan.tiff. It has hyphens, but a generated storage path or document URL might have a long segment with no suitable break point. Normal word wrapping cannot always keep that value inside a narrow column.

Apply emergency breaks to the value, not to all Arabic prose:

.record__filename {
  overflow-wrap: anywhere;
}

MDN's overflow-wrap reference makes an important distinction: anywhere can introduce breaks inside an otherwise unbreakable string when needed, and those opportunities count toward its minimum content size. overflow-wrap: break-word permits similar emergency breaks but does not count them in the same minimum-content calculation. Inside flex or grid, that difference can determine whether the item shrinks at all.

The first fix is still to decide what the value is for. A machine identifier may be technically wrappable yet hard to copy or compare when broken in arbitrary places. If accurate reading or copying matters, consider a labelled local scroll region or a dedicated detail view where it can be seen in full. word-break: break-all applied to a whole record is a poor shortcut: it can split normal words where a natural break would have worked. A readable paragraph should not pay for one unruly filename.

Do not confuse breaking a token with changing its bidirectional behavior. A mixed Arabic and Latin value can be within its box and still render in an unexpected order. Treat that as a separate issue and use the bidirectional text guide when a code, URL or label is reordered. Making the box wider will not repair ordering.

Let the block grow when the title gains lines#

Inline overflow is only half the problem. A fixed height or block-size can cause the second line to collide with a note, border or button below it. If overflow: hidden is also set, the second line vanishes instead. R041 reports visible text-bearing elements that overlap; R042 reports clipped text whose content is wider than its box with overflow hidden and no ellipsis. That latter check is about a specific inline clipping pattern, so do not cite it as proof of every vertically cropped paragraph.

Use a minimum block size when the visual design needs a consistent resting height:

.record {
  min-block-size: 6rem;
}

Let content determine the final height. If a card grid must align rows, consider whether equal height is actually required within each row, or whether a variable-height result is acceptable. The answer depends on the interaction. An archive title is information, not decorative texture.

line-height needs a separate look. The exact room required depends on the font, size, weight and whether the text uses combining marks. W3C's Arabic and Persian layout requirements discusses the positioning of Arabic diacritics and line layout. Do not assume an English line-height token will preserve every mark in the Arabic font.

For body text, R052 reports a line-height below 1.5. Treat that as a signal to inspect the rendered text, not as a claim that 1.5 is sufficient for every typeface and combination of marks. Start with the real font and real content, adjust line-height where lines crowd or marks clip, then remove any fixed block-size that prevents the extra space from being used. Increasing line-height inside a fixed-height clipped box can make the visible result worse. The box must be allowed to grow too.

Try a sample with the actual diacritics your product may display. Many ordinary UI strings contain none; a learning product or digitized manuscript may contain many. A universal Arabic line-height chosen from an unvowelled menu label is not a very impressive universal line-height.

Verify which font actually rendered the Arabic#

The stylesheet can declare a font family that lacks the Arabic glyphs in your content. The browser then uses another font for those glyphs. The result may have different widths and vertical metrics from the font used for English, so the line can wrap or sit differently even when the CSS size has not changed.

The computed font-family tells you the declared stack. It does not prove which face supplied each glyph. Inspect the browser's rendered-font information for the selected Arabic text, and verify that the intended webfont loaded. W3C's font fallback guidance explains why a fallback face can change the result. R050 reports Arabic text falling back past the declared font family, including cases involving a failed webfont.

For a reliable reproduction, test after fonts load, then deliberately disable the webfont once. The first run shows the intended design; the second reveals whether the fallback layout still leaves the record title and action label visible. If the fallback is allowed in production, it belongs in the layout budget. Network failures are rude, but not imaginary.

Avoid “fixing” a font metric problem by applying negative letter-spacing to Arabic. Arabic letters form connected shapes, and tracking can damage that connection. MDN's letter-spacing reference calls out the issue for Arabic script; R051 reports letter-spacing applied to Arabic text. Select a suitable font and size, then adjust the surrounding space.

Truncation is a product choice, not a repair#

There are legitimate reasons to shorten a title in a dense result list. There are also places where the complete text must remain visible: a warning, a permission choice, a button whose final word changes its action, or two records that share the same beginning. Decide based on what a user needs to distinguish, not on whether the CSS demo looks tidy.

For a genuinely optional one-line preview, the familiar combination is:

.record__preview {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

As the MDN text-overflow reference explains, text-overflow only signals inline overflow that is already hidden; it does not cause truncation by itself. With a single ellipsis value, the marker appears at the end of the line's direction. For RTL text that end is the left side. Do not force the title to LTR merely to put the dots where an English mockup put them.

An ellipsis is a disclosure of missing content, not a way to provide it. Give the reader a dependable route to the full title, such as the record detail page or an expansion control. A title tooltip alone does not solve this for touch and keyboard use. Check the actual line at narrow widths: the ellipsis itself consumes space, and a very narrow box can hide almost everything.

Multi-line clamping has its own constraints. MDN notes that the standard line-clamp property has limited availability and describes the older prefixed combination used for compatibility. If you use a clamp, test it in the browsers you support and make the uncut text reachable. Do not count on a line clamp to detect the right place to shorten a meaningful Arabic title. It counts lines. It does not read the catalog.

Test the content and the constraints together#

A single long Arabic string is a useful fixture, but it is not a complete test. Overflow depends on the exact font, container width, siblings and state. Build a small set of cases for each text-bearing component:

• The shortest and longest real Arabic translations available.
• A title that wraps naturally between Arabic words.
• A value with a long unbroken segment, such as an imported filename.
• Text with diacritics if the product can contain them.
• A state that adds a validation note, badge or second action.
• The narrowest supported container and the width just before its layout changes.
• The intended webfont and its fallback.

Inspect at normal size and with text enlarged. Confirm that the full text needed for the task is visible, actions remain distinct, and no line sits beneath another element. Repeat in the LTR version so a fix for Arabic has not changed the original relationship between copy and controls.

For automated checks, measure what the component promises. A title that must be fully visible should not have its scroll width exceed its client width or its scroll height exceed its client height while clipped. A title intentionally truncated is a different case: assert that the complete text is accessible through the chosen detail or expansion path. Geometry alone cannot decide whether truncation was acceptable.

If the entire document becomes wider, R040 reports document-level horizontal overflow. The horizontal overflow guide covers the page-level search for the escaping element. Keep the component test here focused on the text box and its immediate layout. Hiding document overflow at the root can remove the scrollbar while leaving the title unavailable, which is less a fix than an evidence disposal programme.

Give the words a place to go#

The durable fix is usually mundane: remove a size that was based on one language, allow wrapping where prose belongs, let the text item shrink within flex or grid, and let the block grow when another line appears. For the exceptions, decide whether a long token should wrap, scroll locally or open in a detail view. Check the rendered font before blaming translation length.

A free Ritla scan can point you to clipped text, overlapping labels, fixed-pixel containers that cannot hold Arabic and document overflow. Use those findings to inspect the specific component at its failing width. If the box fits but the letters still look cramped, the next useful stop is the RTL CSS guide for the layout properties around it. The aim is simple: the archive title should remain a title, not a riddle with an ellipsis at the end.