Arabic RTL UI design: a practical guide for bilingual products

Arabic RTL UI design is the work of making an interface read naturally from right to left for Arabic users. The layout, the navigation and every icon that points somewhere follow the reading direction, while numbers, phone numbers, logos, clocks and media controls keep their usual form. (In chip engineering, RTL means register-transfer level. Here it only ever means right-to-left user interfaces.)

Getting it right takes more than a mirrored copy of the English screens. You decide what flips and what stays, set Arabic type that reads well at small sizes, hold Arabic and English together in one line, lay everything out with start and end, and test with real Arabic content before anyone writes code.

This guide covers all of that, with sources from the W3C, Apple and Google's Material Design, and examples from my own UI/UX work: apps for charities and shops in Kuwait, the Healoff pharmacy store, the bilingual SkillUp MENA website, and this portfolio.

What right-to-left means in an interface

Arabic is read from right to left, so an Arabic screen starts on the right. The logo and the main navigation sit at the top right, the first tab is the rightmost one, and the eye moves left and down from there. Time flows the same way. In Material Design's words, in a right-to-left layout forward points to the left and back points to the right.

An Arabic interface is also almost always bidirectional (bidi): it mixes right-to-left Arabic with left-to-right brand names, emails, links and numbers. That is where most problems live. Flipping a layout is easy. Keeping a sentence with an English product name, a price and a phone number in the right order is the real craft.

What mirrors and what does not

Apple's Human Interface Guidelines on right to left and Material Design's bidirectionality guidance agree on most of it. The rule underneath both: mirror what shows direction or order, and keep what shows a real object, a brand or a universal sign.

Elements that mirror

• Layout and order: columns, cards in a row, tabs, checkout steps, breadcrumbs. Material notes that navigation buttons appear in reverse order.
• Back and forward: in Apple's words, in the right-to-left context a back button must point to the right.
• Progress from one value to another: sliders and progress bars fill from right to left. If they carry numbers, Apple says the order of the numbers is reversed, but the numerals themselves never flip.
• Icons that show text or reading direction: text alignment, a bulleted list, a chat bubble with lines in it.
• Icons that show forward or backward motion: arrows, chevrons, a send icon.
• Icons inside text fields: Material moves them to the opposite side of the field, with the padding around them.

Elements that stay as they are

• Logos. Apple warns that a flipped logo confuses people and can have legal consequences, even when it contains text.
• Universal signs such as the checkmark.
• Real-world objects such as a clock or a camera. Clocks turn clockwise in every language.
• Media playback controls and the media progress bar. Material keeps them as they are, because they describe the direction of the media, not the direction of reading.
• Charts and graphs, which Material lists among the things that are not mirrored.
• Photographs and illustrations. Apple advises against flipping them, since it changes their meaning, and flipping a copyrighted image could be a violation.

Numbers, phone numbers, emails and links

Some content keeps its own direction inside an Arabic screen. Apple says the digits of a specific number, such as a phone or card number, always appear in the same order. Material says left-to-right words, such as a URL, keep their form even when the rest of the interface is right to left. Treat them as small left-to-right islands: phone numbers, emails, links, order numbers, discount codes and product names in Latin letters.

Where the two platforms differ on a detail, follow the one you ship on, and decide the same way everywhere.

Arabic typography in the interface

An interface makes the differences between Arabic and Latin type obvious, because text sits in small boxes with fixed heights.

Size and visual balance

At the same point size, Arabic often looks smaller than Latin, especially next to capitals. Apple notes that Arabic has no uppercase, and that next to all-caps Latin text it often works to increase the Arabic size by about 2 points. Treat that as a starting point and judge by eye in buttons, labels and tabs. And choose an Arabic face made for screens: many beautiful Arabic fonts are built for headlines or print, with details that disappear at small sizes.

Line height and diacritics

The W3C's Arabic and Persian Layout Requirements notes that Arabic ascenders and descenders extend much further than Latin ones. So Arabic needs more line height than English at the same size, and fixed-height buttons, chips and table rows need room for tall letters, tails and dots.

Most interface text has no diacritics (tashkeel). If your product shows Quranic text, children's learning content or names that need vowel marks, test with them from the start, because the marks need even more vertical space.

Weights, emphasis and spacing

• Check the weights. Many Arabic families have fewer weights than their Latin partners. Make sure yours has every weight your type scale uses, and avoid very thin weights at small sizes.
• No italics. Arabic has no true italic. Use weight or colour for emphasis.
• No letter spacing. Arabic letters join, and tracking pulls them apart.
• Pair by eye. The Arabic and Latin faces should feel the same size and weight side by side. My guide to choosing brand fonts covers pairing in more depth.

Western or Arabic-Indic numerals

Arabic uses two sets of digits: Western digits (0 to 9) and Arabic-Indic digits. According to the W3C layout requirements, Western digits are traditional in western Arab countries such as Morocco and Algeria, and Arabic-Indic digits in eastern ones, including Egypt and Saudi Arabia. Apple confirms that Arabic text might use either.

Yet many digital products in the Gulf and Egypt use Western digits, for practical reasons:

• Phone numbers, card numbers and promo codes are already printed in Western digits in many places.
• The Arabic and English versions can share the same number formats, which makes the product simpler to build and check.
• Prices and codes sit next to Latin brand names and look consistent with them.

Neither choice is wrong. The mistake is mixing them on one screen. Decide once, write it into the mirroring list, and apply it to prices, dates, times, counters and badges. On this blog, the Arabic articles use Western digits throughout.

Whichever set you choose, numbers read from left to right inside the Arabic line: the W3C notes that in all Arabic numeral systems the highest digits sit on the left.

Mixed Arabic and English in one line

A typical bug: an Arabic sentence ends with an English product name, and the full stop jumps to the wrong end. Or an Arabic label is followed by a phone number with a plus sign, and the plus lands on the other side. The browser is following the Unicode bidirectional algorithm, which has to guess where punctuation and numbers belong when they sit between two directions.

The fix is to tell it. The W3C article on inline markup and bidirectional text gives three rules:

• Wrap every opposite-direction phrase tightly in markup that sets its direction, such as a span with dir="ltr" around an English name in Arabic text.
• Isolate content you do not control. User names, product titles and search terms can be in either language. The bdi element, or dir="auto", lets the browser decide from the first strong character and keeps that text from disturbing its neighbours.
• Prefer markup to invisible control characters, because markup is easier to see and manage.

Your part as a designer is to show these cases in the mockups: an English brand at the end of an Arabic line, a phone number in a label. If the mockup shows it, the developer builds for it.

Forms and input

Forms are where right-to-left design meets real data, and where small mistakes cost real orders.

Field direction and placeholders

• Labels and help text are in Arabic and aligned to the start, which is the right.
• Email, URL, password, phone and card fields hold left-to-right content. Set them to dir="ltr" so the cursor and characters behave as people expect.
• Free text fields such as names and addresses can be filled in either language. The W3C suggests dir="auto" on such inputs, so the field follows what the person types.
• A placeholder is not a label. It disappears once someone types. Keep a visible Arabic label above the field, and use the placeholder for a format hint such as name@example.com. In a left-to-right field, an Arabic placeholder will sit on the left, so write it as a left-to-right example or align it on purpose.

Validation messages

• Write them in clear Arabic, next to the field, and say what to do. «يرجى إدخال رقم هاتف صحيح» ("please enter a valid phone number") helps; «خطأ» ("error") does not.
• Arabic verbs change with gender, so a plain command speaks to a man or to a woman. Many teams use phrasing that works for everyone, like the polite form above, or a statement such as «البريد الإلكتروني مطلوب» ("email is required").
• Do not rely on red alone. Pair the colour with an icon and words.

Keyboards and digits

• Use the right input types, such as type="email", type="tel" and inputmode="numeric", so phones show the right keyboard.
• People on an Arabic keyboard may type Arabic-Indic digits into a phone or code field. Accept both sets and convert them before checking, or the form will reject a perfectly good number.
• One-time codes, card numbers and phone numbers keep their left-to-right order, in separate boxes too.
• Plan for long names. In the Gulf, a full name often has four parts.

Layout with start and end, not left and right

The most useful habit in Arabic RTL UI design is a change of vocabulary: stop saying left and right, and say start and end. In Arabic, start is the right; in English, it is the left. A card with a 16 start padding is correct in both languages. A card with a 16 left padding is wrong in one of them.

On the web, CSS speaks this language through logical properties. margin-inline-start, padding-inline-end, inset-inline-start and text-align: start follow the direction of the page, and flexbox and grid already do. Set dir="rtl" on the html element of Arabic pages and the layout mirrors on its own. The W3C article on structural markup and right-to-left text explains this, and advises against setting the base direction with CSS.

Two traps to avoid:

• Faking right-to-left with flex-direction: row-reverse. It looks right, but the reading and focus order no longer match what people see.
• Mirroring every icon with one rule. Mirror only the icons on your "flips" list. Apple's SF Symbols, for example, include right-to-left variants for the symbols that need one.

The same thinking belongs in the design file. Name spacing by start and end, build rows with auto layout so they can be reordered, and treat the Arabic frames as real designs, not flipped copies. If frames and auto layout are new to you, start with my Figma guide for beginners.

Navigation and gestures

• Back and forward: the back arrow points right, and a "next" arrow points left.
• Tab bars: the first tab, usually home, sits on the right.
• Side menus: the drawer opens from the right edge.
• Carousels and onboarding: the first slide is on the right and the next comes in from the left, so people swipe from left to right to move forward.
• Screen transitions: a new screen slides in from the left, because forward points left.
• Swipe actions on list rows: iOS calls them leading and trailing actions, so they swap sides with the layout.

One exception, from Apple: a control that means a real direction, such as "to the right" on a map, must always point that way.

A bilingual content strategy

In a bilingual product, the content needs as much planning as the layout.

• Give each language its own address. Google recommends a different URL for each language version rather than cookies or browser settings, suggests linking the versions with hreflang, and advises against redirecting people automatically to the language you guess for them.
• Make the language switch a link to the same page in the other language, not to the home page. Label each language in its own script: «العربية» and English. Flags stand for countries, not languages.
• Write each language for its reader. A word-for-word translation reads like one.
• Expect different lengths, so buttons, tabs and cards need room to grow.
• Localise images that contain text, including app store screenshots and banners.

This portfolio is built that way. Every page has an Arabic and an English version, each at its own address under /ar and /en, and the Arabic is a real right-to-left layout, not a flipped English page. I designed it and built it with Claude Code as my tool. If you want to build your own interfaces the same way, read my guide to vibe coding for designers. The tools build what you ask for, so the right-to-left rules have to be in your first request and in your review of every page.

Testing with real Arabic content

Lorem ipsum hides every problem in this guide. So does Arabic filler text, which has the right letters and the wrong words.

1. Write real copy early, even rough, in both languages.
2. Use the longest real cases: four-part names, long product titles, the biggest price.
3. Mix the scripts: English brand names inside Arabic sentences, and emails and phone numbers in labels.
4. Check truncation. In Arabic the ellipsis belongs at the end of the line, on the left.
5. Test on real phones set to Arabic, on iOS and Android, since system controls follow the device language.
6. Switch languages in the middle of a task, with items in the cart, and check that nothing is lost.
7. Listen to it with VoiceOver or TalkBack in Arabic.

Accessibility: lang, dir and screen readers

Two attributes on the html element do a lot of work: lang="ar" and dir="rtl". The W3C article on declaring language in HTML asks you to always declare the page language there, to mark any change of language inside the page, and to add dir for bidirectional text.

This matters most for screen reader users. WCAG asks for the language of the page (success criterion 3.1.1, level A) and for changes of language inside it (3.1.2 Language of Parts, level AA), so a screen reader can use the right pronunciation for each passage. An English product name inside an Arabic page should carry lang="en".

One detail surprises people: Google says it uses the visible content of a page to decide its language, not the lang attribute. So lang is not a search trick; it serves browsers, fonts and assistive technology.

Also give icon buttons Arabic accessible names, keep the code order the same as the visual order, and keep contrast high for small Arabic text.

Handing off to developers

A good handoff turns everything above into decisions nobody has to guess.

• Specs in start and end. If the inspect panel says left, add a note that left in the English frame means start.
• The mirroring list: what flips, what stays, which digits, how dates, times and prices look. Currency belongs here too: the Kuwaiti dinar is divided into 1,000 fils, so a store in Kuwait often shows prices with three decimal places.
• Icons marked "mirror" or "keep", so nobody flips a clock or a logo by accident.
• Key screens in both directions, especially those with mixed content: product pages, checkout, profile, search results.
• Type styles per language: Arabic and English sizes, line heights and weights as separate styles.
• Edge cases as real strings: an English brand inside an Arabic sentence, a long name, a phone number with its country code.
• A review of the build in both languages on real devices before launch.

From my work

At Aldar International in Kuwait I designed apps and websites for charities, a cancer care society, a consulate and the company itself, plus two shopping apps: Bkam for groceries and Cramello for desserts. Each product started from its flows and a small design system, and the delivery included design systems and handover files. A small system is exactly where right-to-left rules belong: once the components know about start and end, every new screen inherits them.

Healoff, also designed at Aldar, is a pharmacy and beauty store that sells online in Kuwait, in Arabic and English. I designed the mark, the shopping app for iOS and Android, the app store screenshots, the website and the campaign banners. The store puts categories first and keeps checkout to a few taps. A store like this meets the cases in this guide on almost every screen: product names in Latin letters, prices, order numbers.

On the bilingual SkillUp MENA website, I lead the project, design the interface and build it, so I sit on both sides of the handoff, and the same list still applies.

If you show bilingual interfaces in your own portfolio, put the Arabic and English screens side by side; my design portfolio guide covers the rest.

Conclusion

Arabic RTL UI design is not a mirror. It is a set of decisions: what follows the reading direction, what stays fixed, how Arabic type sits next to Latin, which digits to use, and how mixed text holds together. Write those decisions down once, design with start and end, test with real Arabic content, and hand the list to developers with the screens.

If you need a bilingual app or website designed with that care, start a project with me.