Arabic-first UX: RTL mistakes that make apps feel foreign

Why some apps feel 'translated' even when every word is Arabic

A user opens the app. The text is Arabic and the menu sits on the right, yet something feels off: the 'next' arrow points backward, the phone number renders with the plus sign at the wrong end, paragraphs feel cramped, and search can't find a customer because the name was saved without its hamza. Each issue is small. Together they tell the user: this product wasn't made for you.

The good news is that these mistakes are well known and repeat across almost every project, and fixing them rarely requires a rebuild. This guide walks through eight areas where most problems live, with the practical fix for each and what to ask of your team or the Fanann Agent when you build.

RTL is not a filter you apply at the end. It is a design decision that starts with the first screen.

• Layout and icons: what mirrors and what stays put.
• Numbers and bidirectional text: when Arabic, English and digits share a line.
• Fonts and line-height: why Latin type settings fail Arabic.
• Dates: Hijri, Gregorian and month names.
• Names, addresses and phones: forms that respect local reality.
• Search: normalizing Arabic letter variants.

Mirroring layout and icons: not everything flips

There are two opposite classic mistakes. One team forgets to mirror directional icons, so the back arrow still points left. Another flips everything, including the checkmark, the play button and the logo. The rule is simple: mirror what represents direction or a timeline; leave what represents a real-world object.

In code, the biggest source of bugs is physical direction properties like margin-left, padding-right and text-align: left. Use logical properties instead, such as margin-inline-start, padding-inline-end and text-align: start, which flip automatically with page direction. In Tailwind, that means ms- and me- instead of ml- and mr-.

Numbers and bidi text: when Arabic meets English

Arabic users read and write mixed text constantly: an order number with a hash sign, an iPhone model name, 'paid with Apple Pay'. The browser lays this out with the Unicode bidirectional algorithm, which usually works, but it stumbles at the edges: an exclamation mark jumps to the start of the line, the # sticks to the wrong side, or +966 renders with the plus at the end.

• Isolate dynamic content: wrap every user name, product name or number inserted into an Arabic sentence in an isolated element (bdi, or unicode-bidi: isolate) so its direction doesn't leak into the surrounding text.
• Make inputs smart: use dir=auto on general text fields so direction follows the first character the user types.
• Phones, cards and emails: keep these fields LTR even in an Arabic UI; right-align the text if you want visual consistency.
• Digits: pick one display system (Western 0-9 is widespread in the Gulf) and stay consistent, but accept Arabic-Indic digits in input and convert them before saving.
• Currency: fix the symbol position and spacing explicitly, for example '150 SAR' or the Arabic abbreviation, instead of letting the browser decide.

Fonts and line-height: Arabic needs more room

Arabic letters have tall ascenders, deep descenders, dots above and below, and optional diacritics, so a paragraph set with Latin type settings looks cramped. And if you don't specify an Arabic font at all, the operating system picks a fallback that differs per device, so the app looks different on every phone.

• Choose an Arabic font designed for screens and load it explicitly. Pick one with multiple real weights so the browser doesn't fake bold.
• Increase line-height: what works for English (around 1.4 to 1.5) is often tight for Arabic; try 1.6 to 1.9 for body text.
• Go slightly larger: the same numeric size looks smaller in Arabic because of its relatively small x-height equivalent; one or two points more helps readability a lot.
• Never apply letter-spacing to Arabic: spacing breaks the connections between letters and shatters words.
• Don't rely on uppercase for headings: it has no meaning in Arabic, so use weight or color instead.
• Leave room for text: Arabic strings can be shorter or longer than English; design buttons and cards with flexible widths, not fixed ones.

Dates and times: Hijri and gregorian together

In Saudi Arabia and across the Gulf, people live with two calendars: Gregorian for most daily transactions and Hijri for religious occasions and some official documents. Gregorian-only may be fine for a store, but a Ramadan booking app, a government-facing service or a payroll tool may need both.

Names, addresses and phone numbers: forms that fit reality

Forms copied from Western templates assume everyone has a first and last name and every address has a postcode, street name and building number. Reality in the region is more varied: four-part names, addresses described by landmarks, and customers who would rather drop a pin on a map.

Names

• Allow long and compound names such as Abdul Rahman or Al Saud, and don't treat a space inside a first name as an error.
• If you don't truly need split names, use a single 'Full name' field.
• Accept Arabic and Latin characters, and don't strip diacritics or hamza on save (normalize only for search).

Addresses

• Make postcode optional in most cases, and add a 'details or nearest landmark' field.
• Support picking a location on a map; it is what many couriers actually rely on.
• In Saudi Arabia, allow the National Address or its short-address form where relevant, and check the official format at its source.

Phone numbers

Users may type the leading zero, the country code, a 00 prefix, spaces or dashes. Accept all of it, then convert to one international format (E.164) before saving and before sending an OTP. Default the country picker to the user's country.

Arabic search: normalize letters before you compare

If a user types a word ending in haa and your catalog spells it with taa marbuta, they won't blame their spelling; they'll decide your search is broken. Several Arabic letters are written in more than one way depending on habit and keyboard, so normalize both the query and the stored data with the same rules before comparing.

Normalization improves results dramatically but isn't the whole story. For stores and large catalogs, add synonyms (the several Arabic words people use for 'mobile phone'), support Arabic and English names for the same product, and tolerate small typos. For content-heavy apps, semantic search can help; see our article on RAG.

Do and don't: a pre-launch checklist

1. 1
   Mirror review

   Compare every screen in Arabic and English side by side and look for anything that didn't flip, or flipped wrongly.

2. 2
   Real-data test

   Enter a long four-part name, an address without a postcode, a phone in Arabic-Indic digits, and a product name mixing Arabic and English.

3. 3
   Multi-device test

   Try an iPhone, an Android phone and a small screen to check fonts, wrapping and responsive design.

4. 4
   Real users

   Ask three to five people from your audience to complete one task and watch where they hesitate; it reveals what checklists miss.

If you build with AI, state these requirements explicitly in your first description, since the agent follows what you write. You'll find plenty of examples in our prompting guide, and a full quality checklist in testing AI-generated code.

Frequently asked questions

Terms in this article