Arabic RTL UI Design: The Complete Guide for SaaS Teams

Most teams discover their Arabic problem after launch. The build looked fine in review, the translations came back approved, and then Gulf users started dropping out of the signup flow at a rate nobody could explain. The cause is almost never the translation. It is that right-to-left was treated as a rendering setting rather than a design pass.

This guide covers what actually changes when a SaaS product goes right-to-left: which elements mirror, which must never mirror, how numbers and dates break, why Arabic typography needs its own spacing decisions, and how to run one codebase across both directions without maintaining two designs.

RTL is not direction: rtl

Setting dir="rtl" on the root element flips text alignment and the reading order of inline content. That is roughly ten percent of the work. Everything positioned with explicit left and right values stays exactly where it was, which produces the characteristic half-mirrored interface: text runs right-to-left, but the sidebar, the close button, the dropdown caret and the progress bar all sit on the wrong side.

The result reads as unfinished to a native speaker in the same way a machine-translated landing page reads as unfinished to you. Users rarely file a bug about it. They just trust the product less, and in financial products that trust gap shows up directly in conversion.

What mirrors, and what must never mirror

This is where most RTL implementations go wrong in both directions — under-mirroring the layout, then over-mirroring things that carry their own meaning.

Mirror these

• Page and grid direction, sidebars, drawers and navigation
• Text alignment and list bullet position
• Breadcrumbs and pagination order
• Progress bars and steppers — progress fills from the right
• Directional icons: back and forward arrows, undo and redo, indent, reply
• Carousels and horizontal scroll direction
• Table column order, including the row-label column
• Dropdown carets, tooltips and popover anchor points

Do not mirror these

• Media playback controls. The play triangle points right in every locale. Arabic users learned it from the same devices you did. Mirroring it makes the player look broken.
• Clocks and anything referencing clockwise motion. Time still moves clockwise.
• Numbers themselves. A figure is always written left-to-right, even inside Arabic text.
• Logos, brand marks and product screenshots.
• Checkmarks, and icons whose shape is conventional rather than directional — search, settings, notifications.
• Code, terminal output and file paths.

Charts sit in a genuinely contested middle. A time-series axis reading right-to-left matches Arabic reading order and is common in Gulf financial software; a chart copied straight from an English dashboard with the axis unchanged is also widely understood. Pick one, apply it consistently across the product, and state the decision in your design system so it does not get re-litigated every sprint. What breaks trust is a dashboard where two charts disagree.

Numbers, currency and dates: where the real bugs live

Arabic is a bidirectional script, which means a single string can contain runs in both directions. The Unicode bidirectional algorithm decides how they sit together, and it is doing its best with incomplete information. Concatenate an Arabic label with a Latin product name and a figure, and the parts can reorder in ways that look like a rendering fault but are technically correct behaviour.

Three rules prevent most of it:

1. Isolate every embedded run. Wrap Latin text, numbers, phone numbers and email addresses in an element carrying unicode-bidi: isolate, or use the native <bdi> element. This tells the algorithm to treat the run as one unit rather than negotiating with its neighbours.
2. Never build sentences by concatenation. Use full interpolated strings in your localisation files so translators control word order. "Deleted " + count + " files" cannot be translated correctly into Arabic; "تم حذف {count} ملفاً" can.
3. Decide your numeral system deliberately. Gulf business and financial interfaces overwhelmingly use Western Arabic numerals — 0 to 9, the same glyphs you are reading now. Eastern Arabic numerals (٠١٢٣) are common in Egypt and in more traditional or literary contexts. Defaulting to Eastern numerals in a Saudi banking dashboard because it feels more authentic will make your product harder to scan, not more trusted.

Dates deserve their own decision. Saudi Arabia runs on both the Hijri and Gregorian calendars, and which one is expected depends entirely on context — a government-facing form, a salary date and an international invoice do not have the same answer. If your product touches anything official or salary-linked, showing both is the safe default rather than a nice extra.

Arabic typography needs its own decisions

Arabic removes three of the tools you normally use to build hierarchy. There is no uppercase, no italic and no small caps. Bolding works, but Arabic typefaces often have fewer usable weights than their Latin counterparts, and faux-bolding a connected script degrades it badly.

What replaces them is size, colour, spacing and weight used more deliberately. In practice:

• Increase line-height. Arabic glyphs carry more vertical extent — ascenders, descenders and diacritics all compete for space. Body text that reads comfortably at 1.5 in Inter typically needs 1.7 to 1.9 in Arabic. Copying the English value is the single most common typography mistake.
• Increase font size slightly. Arabic set at the same pixel size as Latin reads smaller, because the meaningful detail sits in the middle of the line. One or two pixels usually resolves it.
• Do not rely on font fallback. Inter, Fraunces, Poppins and most Latin webfonts contain no Arabic glyphs. The browser silently substitutes a system font, letterform joining breaks, and the result looks careless in a way the team may never notice because it renders differently on their machines.
• Plan for length variance. Arabic translations commonly run twenty to thirty percent shorter or longer than the English source depending on register. Fixed-width buttons and single-line labels are where this surfaces first.

Reliable open-source options include IBM Plex Sans Arabic, Noto Sans Arabic, Readex Pro, Cairo and Tajawal. Pair one for UI and, if you need display contrast, choose a second with genuinely different structure rather than a heavier weight of the same family.

Building bilingual without maintaining two designs

Teams usually reach for one of two bad options: a second stylesheet that drifts out of sync within a quarter, or a pile of [dir="rtl"] overrides that grows with every feature.

CSS logical properties remove most of the problem. Instead of describing positions in physical terms, describe them relative to the reading direction, and the browser resolves them per direction:

Written this way, one stylesheet serves both directions and new features inherit correct behaviour by default. Support is universal across current browsers.

A small override sheet is still worth keeping for the things that are genuinely different rather than merely mirrored: the Arabic font stack, adjusted line-heights, and the handful of components where mirroring is the wrong answer. Keeping that sheet deliberately small is what stops the two versions diverging.

Two further habits matter more than they sound. Set lang="ar" alongside dir="rtl", because it drives font selection, hyphenation and screen reader pronunciation independently of direction. And add hreflang pairing between your language versions so search engines serve the right one rather than treating them as duplicates.

Seven mistakes that cost you trust in the Gulf

1. Shipping machine translation without native review. Arabic has strong register distinctions. Copy that is technically correct but tonally wrong — overly formal, or casual where it should be respectful — reads immediately as foreign. This is the fastest way to lose an enterprise buyer.
2. Latin font fallback. Broken letterform joining is visible to every native reader and invisible to most non-native teams.
3. Scrambled mixed strings. Prices, IDs, IBANs and product names reordering inside Arabic sentences. In a financial product this does not read as a rendering quirk. It reads as unreliable.
4. Forms that flip everything. Labels and layout should mirror. Email fields, IBANs, URLs and phone numbers should stay left-to-right, or users cannot verify what they typed.
5. Gregorian-only dates in official contexts. A minor omission in most products; a real obstacle in anything touching Saudi government processes, payroll or compliance.
6. Over-mirroring. Reversed play buttons, flipped logos, mirrored screenshots. Over-correction signals inexperience as clearly as under-correction.
7. Treating Arabic as a toggle rather than a design pass. The layout that works at English string lengths often breaks at Arabic ones. Someone has to look at every screen in Arabic before launch, and that someone should read Arabic.

Pre-launch RTL checklist

Frequently asked questions

Is setting dir="rtl" enough to support Arabic?

No. It flips text alignment and inline reading order, but anything positioned with explicit left or right values stays in place. Sidebars, close buttons, progress bars and dropdown carets all need handling separately, usually by moving component CSS onto logical properties.

Which UI elements should not be mirrored?

Media playback controls, clocks and clockwise motion, numbers themselves, logos and brand marks, product screenshots, code and file paths, and icons whose shape is conventional rather than directional — search, settings, notifications.

Should an Arabic interface use Eastern or Western numerals?

Gulf business and financial interfaces overwhelmingly use Western Arabic numerals (0–9). Eastern Arabic numerals are more common in Egypt and in traditional or literary contexts. Using Eastern numerals in a Saudi financial dashboard generally makes the product harder to scan.

How much line-height does Arabic text need?

Body text that reads comfortably at 1.5 in a Latin typeface typically needs 1.7 to 1.9 in Arabic, because Arabic glyphs carry more vertical extent through ascenders, descenders and diacritics. Copying the Latin value is the most common Arabic typography mistake.

How do you maintain one codebase for both LTR and RTL?

Use CSS logical properties — margin-inline-start, padding-inline-end, inset-inline-start, text-align: start — instead of physical left and right values. The browser resolves them per direction, so one stylesheet serves both and new features inherit correct behaviour by default.

Getting it right the first time is cheaper

Retrofitting RTL into a product designed left-to-right costs several times what building bidirectionally from the start would have. The expensive part is rarely the CSS — it is the component library, the localisation architecture and the design decisions that were never written down, all of which have to be revisited at once.

If a GCC launch is anywhere on your roadmap, the cheapest moment to make these decisions is before your design system hardens. The second cheapest is now.