Designing bilingual products for right-to-left readers

Designing for right-to-left (RTL) readers means much more than mirroring the layout. Mirror the structure with logical CSS properties, decide icon by icon what flips, set Arabic type on its own terms, handle numbers and mixed Latin text on purpose, and write the copy natively. Then test with real Arabic text from the first week, not the last.

The sections below follow that order. They are written for Arabic and English in one product, and most points also apply to other right-to-left languages such as Hebrew and Persian.

Start with logical properties, not mirrored styles

Physical CSS properties such as margin-left point at a side of the screen. Logical properties such as margin-inline-start point at a side of the text, so they flip when the page direction flips. Set the page direction to rtl and the language to ar on the html element, write layout in logical terms, and one component serves both languages.

• Margins and padding: use the inline-start and inline-end forms instead of left and right.
• Text alignment: use start and end instead of left and right.
• Positioning: use inset-inline-start and inset-inline-end instead of left and right offsets.
• Tailwind CSS offers the same idea as utilities such as ms-4, pe-4 and start-0, plus an rtl: variant for the exceptions.

Flexbox and grid already follow the page direction, so a row of items reverses without extra code. The exceptions are the physical things: transforms, gradients, shadows and background positions. A fade-out gradient on a carousel edge, a translateX animation and a shadow offset to the right will all point the wrong way until you flip them on purpose.

Decide which icons and images mirror

The rule is easy to state and needs judgement to apply: mirror an icon when its meaning depends on reading direction or on progress, and keep it when it shows a real object or a brand.

• **Mirror:** back and forward arrows, chevrons in lists and breadcrumbs, step indicators, reply and send icons, indent icons, and sliders and progress bars that fill from the start edge.
• **Keep:** logos, clocks (the hands still turn clockwise), checkmarks, plus and close signs, photographs, maps and icons of real objects such as a phone or a camera.
• **Check case by case:** media controls and timelines. Many guidelines keep play and rewind as they are, because they describe time, not reading order.

Keep a list in the design system that marks each icon as mirrored or fixed, so developers do not decide one at a time. Images that contain words need a version per language; better still, keep words out of images.

Set Arabic type on its own terms

Arabic is a cursive script: letters connect and change shape by position, so the rules for Latin type do not carry over. Never add letter-spacing to Arabic text, because it breaks the joins. Do not use italics or capitals. Arabic has neither, and a fake slant looks wrong to readers.

Line height matters more than most teams expect. Arabic has tall letterforms and marks above and below the line, so a Latin line height tuned for headings can make lines collide or clip. A line height of roughly 1.6 to 1.8 times the font size is a common starting point for body text, and headings usually need more room than their Latin equivalents. Treat the numbers as a starting point and check them with your typeface and real text.

Arabic type often looks smaller than Latin type of the same size, so match the two by eye, not by number. Choose a family with matching Latin and Arabic cuts, such as IBM Plex Sans with IBM Plex Sans Arabic. Avoid very light weights on small text, where thin strokes and dots blur.

Handle numerals, dates and mixed-direction text

Numbers are the first place where mixed direction shows up. Digits always run left to right, even inside a right-to-left sentence, so a phone number, a price or a card number must stay one left-to-right unit. Readers also differ on which digits they expect: Western digits (0 to 9) or Eastern Arabic-Indic digits. Choose by audience, stay consistent within a screen, and format with the browser's Intl APIs instead of by hand.

Dates need the same care. Some readers expect the Hijri calendar, alone or beside the Gregorian one, and the first day of the week and the weekend differ by country, so a date picker should follow the locale instead of assuming Monday to Friday.

Mixed text causes the classic bug: a full stop or bracket that jumps to the wrong end of a sentence after a Latin name. Wrap inserted names, product names and codes in the bdi element (or give them dir=ltr) so the browser isolates them, and use dir=auto on fields that hold user-written text.

Forms, tables and charts

In forms, labels and fields align to the start edge and the field order mirrors. Fields that hold Latin-only values, such as email addresses, URLs and card numbers, stay left to right, so set their direction explicitly and check how the cursor, placeholder and error message line up. Never reject Arabic letters in names, and make search forgiving: normalise alef variants, diacritics and the stretching character before comparing, and sort with a locale-aware collator.

Tables mirror as a whole: the first column sits on the right, and numeric columns align to the end edge so figures still line up. Charts are less settled. Many guidelines mirror charts whose horizontal axis is time, so the oldest value is on the right, and keep charts that use a numeric scale. Either choice can be defended; the failure is mixing them in one dashboard. Pick a rule, apply it everywhere and check it with Arabic readers.

Motion and gestures

Horizontal motion follows reading direction. A drawer slides in from the start edge, the next card in a carousel sits on the left, a progress bar fills from the start, and swipe-to-go-back gestures flip with the layout. Vertical motion stays as it is. Drive this from one direction variable (1 or -1) instead of writing two animations, and respect the reduced-motion setting in both languages.

Write for the language, then test

Native Arabic copy reads better than a literal translation, and it behaves differently in the interface. Arabic has six plural forms (zero, one, two, few, many and other), so a counter such as the number of items in a basket needs a plural-aware message format, not one if-else. Verbs and adjectives carry gender, so decide how you address the user. Never build sentences from fragments, and leave room for text that is longer or shorter than the English.

Test early with real Arabic strings, never lorem ipsum or flipped English. Flip the whole interface to RTL in the first build, review every screen and every state (empty, error, long text), and include user-written content that mixes Latin and Arabic. Set the lang attribute on each language fragment so screen readers pick the right voice. Then ask a native reader to review the result: they catch tone and wording that no checklist can.

We design and build English and Arabic together on every project, with weekly demos so you see both versions develop. For more, see the [Arabic and RTL design service](/services/ui-ux-design/arabic-rtl-design), the [definition of RTL design](/glossary/rtl-design) and the [guide to bilingual Arabic and English products](/guides/bilingual-arabic-english-products).