Guide · 16 September 2026 · 5 min read
Arabic UI design: twelve things that go wrong in right-to-left interfaces , and how to fix them
The mistakes we see most in Arabic and RTL products, from mirrored icons and Latin fallback fonts to numerals, dates, currency, forms and mixed-direction strings, with the fix for each.
By Daniel Makhamreh, lead designer at Recast
Most Arabic interfaces are English interfaces with the layout flipped and the strings replaced. They work, in the sense that nothing crashes. They also read as translated, to every Arabic-speaking user, within seconds. The tell is never one big thing. It is a dozen small ones, and this guide lists the twelve we fix most often, in the order we usually find them.
The principle behind all of them: an Arabic screen is a version of the design, not a transformation of it. It has to be set by someone who reads it.
1. Mirroring everything
Flipping the layout is right. Flipping every icon is not. Direction icons mirror: back arrows, "next" chevrons, progress indicators, indent controls. Icons that depict a real object or a convention do not: clocks, play buttons, checkmarks, logos, the search magnifier, a phone handset, media controls, anything with text in it.
The fix: an explicit list in the design system of which icons mirror. In code, apply the flip per icon, not with a blanket transform on the icon set.
2. Arabic set in a Latin fallback font
The English UI uses a typeface with no Arabic glyphs, so the browser substitutes whatever Arabic font the operating system has. Weights disappear, the baseline shifts, and the same screen looks different on every device.
The fix: choose an Arabic family deliberately and pair it with the Latin one on x-height and weight. IBM Plex Sans Arabic, Noto Naskh Arabic, Cairo and Tajawal are all sound; the pairing matters more than the pick. Load the weights you use, and set the family per language with the lang attribute, not per page.
3. Line height and clipped marks
Arabic has taller ascenders and deeper descenders than Latin, and diacritics sit above and below the letters. Line heights tuned for English clip them in inputs, chips and buttons, and crowd them in body text.
The fix: larger line height for Arabic text, typically 1.6 to 1.8 for body copy against 1.4 to 1.5 in English, and a few pixels more vertical padding in any control that holds a single line.
4. Inconsistent numerals
Some screens show Western Arabic digits (1, 2, 3), some show Eastern Arabic digits (١, ٢, ٣), and prices, dates and phone numbers do not agree with each other.
The fix: decide per market and apply it everywhere. Saudi Arabia, the UAE and most product interfaces use Western digits; Eastern digits are common in Egypt and in editorial contexts. Phone numbers, card numbers and codes stay Western regardless. Write the rule into the design system.
5. Mixed-direction strings
An Arabic sentence with an English product name, an email address or a number range inside it renders with the pieces in the wrong order, because the bidirectional algorithm is guessing.
The fix: isolate the embedded run. In HTML, wrap it in an element with dir="auto" or use the bdi element; in strings that are assembled in code, wrap the run with the Unicode isolate characters. Never assemble Arabic sentences from concatenated fragments.
6. Physical alignment instead of logical
Text aligned "left" and margins set "left" in the stylesheet stay left in Arabic, so labels drift away from their fields and lists hang off the wrong edge.
The fix: logical properties throughout: text-align: start, margin-inline-start, padding-inline-end, inset-inline. Flexbox and grid follow the document direction on their own when you use start and end rather than left and right.
7. Dates and calendars
Dates arrive in an English pattern with the month name swapped, or the Hijri calendar is missing where the market expects it.
The fix: format dates with the locale, not a template. In Saudi Arabia show Hijri where it is expected (official dates, government products) and Gregorian elsewhere, and never mix them on one screen without labelling. Day and month order follow the locale; digits follow rule 4.
8. Currency and units
Currency symbols land on the wrong side of the amount, the wrong abbreviation is used, or the amount and symbol split across a line.
The fix: SAR and AED are usually written after the number in Arabic interfaces (١٢٠ ر.س or 120 SAR) and before it in English ones, and the new Saudi riyal symbol is entering use in 2026. Keep the number and the unit together with a non-breaking space, and treat the pattern as a locale setting, not a string.
9. Forms that fight the user
Inputs for email addresses, URLs, phone numbers and codes are set right-to-left because the page is, so the caret jumps and the text reorders as the user types. Placeholders are in the wrong language. Error messages sit on the wrong side.
The fix: direction per field. Email, URL, phone and code fields are always left-to-right, even on an Arabic page. Everything else follows the page. Placeholders, helper text and errors are written in Arabic by a person, and positioned with logical properties so they land beside the field.
10. Truncation and text expansion
Arabic runs longer than English in some strings and shorter in others. Buttons that fit "Save changes" clip its Arabic equivalent; tabs designed for one word get two.
The fix: design the Arabic screen with the real Arabic strings, including the longest one, and give controls room to grow. Truncate with an ellipsis only where the full text is available on hover or tap, and never truncate a label the user has to act on.
11. Tracking, capitals and Latin habits
Letter-spacing applied to Arabic breaks the connections between letters, because Arabic is a joined script. Uppercase transforms do nothing, and the "small caps eyebrow" style so common in English interfaces has no Arabic equivalent.
The fix: no letter-spacing on Arabic text, ever. Replace uppercase eyebrows with a weight or size change. Emphasis in Arabic comes from size, weight and colour, not from spacing or case.
12. Testing with placeholder text
The Arabic screen was reviewed with lorem ipsum, or with machine-translated strings, by someone who does not read it. It looked fine. It is not.
The fix: review with real content, in a browser, in both directions, with an Arabic reader. Switch the language live and check that every element moves with it, including toasts, modals, tooltips and the parts drawn by third-party libraries. Keep a checklist; the same six things break every time.
Designing it as a version
Every fix above is small. Together they are the difference between a product that was localised and a product that was designed for the people using it. The reliable way to get there is to have the Arabic version designed alongside the English one, by a designer who reads it, from the first screen, with the rules written into the design system so engineers do not have to guess.
That is how Arabic and RTL design works on every Recast plan: set, not substituted, and built right-to-left rather than mirrored. If you want to see it on one of your own screens, the $490 pilot sprint delivers a real screen in both directions in five working days.
See it on your own screen, in five days.
The $490 pilot sprint takes one real screen from your product through the same process: two directions, every state, a spec frame, Figma with tokens. Credited against your first month if you continue.
From $1,999/mo. 14-day full refund on every self-serve plan. Pause any month — unused days carry forward.