The Arabic & RTL checklist for apps and websites (2026)

Most Arabic versions of apps and websites fail in the same places: a back arrow pointing the wrong way, a phone number scrambled by bidirectional text, a font that turns Arabic into thin, cramped shapes, or a search box that can't find "احمد" when the user types "أحمد". None of these are hard to fix. They are just easy to miss if nobody on the team reads Arabic daily.

We are native Arabic speakers who build bilingual products, and this is the checklist we use ourselves. It is written for developers, designers and product owners. Use it before a launch, during a design review, or to audit an existing product.

Before you start: three decisions

Make these once, write them down, and apply them everywhere:

1. Arabic-first or English-first? If most users read Arabic, design in Arabic first. It is much easier to adapt an Arabic layout to English than the reverse.
2. Which numerals? Western digits (0123) or Arabic-Indic digits (٠١٢٣). Usage varies by country, audience and brand. Pick one per language and be consistent.
3. Which markets? Saudi Arabia, the UAE, Egypt and the Levant differ in calendars, week start, month names, currency formats and tone.

1. Layout direction

• Set dir="rtl" and lang="ar" on the root html element, not only a CSS direction rule. The lang attribute also tells screen readers to use an Arabic voice.
• Use logical CSS properties: margin-inline-start, padding-inline-end, inset-inline-start, border-inline-end, text-align: start. They flip automatically with direction.
• In Tailwind CSS, use ms-*, me-*, ps-*, pe-*, start-*, end-*, and the rtl: variant only for genuine exceptions.
• Don't "fix" RTL with flex-direction: row-reverse. Flexbox and grid already follow the document direction; reversing them breaks again when direction changes.
• Check the properties that do not flip: absolute positions written with left/right, transform: translateX(), background-position, shadow offsets and hand-written animations.
• Reverse carousels, sliders, steppers, progress bars and swipe gestures: in Arabic, "next" is to the left.
• Decide deliberately how charts with a time axis should run, and keep it consistent across the product.

Flutter: use EdgeInsetsDirectional, AlignmentDirectional, PositionedDirectional and BorderRadiusDirectional instead of their left/right versions. With flutter_localizations and an Arabic locale, the app's Directionality becomes RTL automatically.

React Native: use marginStart, marginEnd, paddingStart, paddingEnd, start and end. Changing direction with I18nManager.forceRTL only takes effect after the app restarts, so plan the language switch around that.

Native Android and iOS: declare android:supportsRtl="true" in the Android manifest and use start/end attributes; on iOS use leading/trailing constraints rather than left/right.

2. Icons: what to mirror and what to leave alone

The rule: mirror icons that show direction or progress through time. Leave alone icons that show real-world objects or that have a fixed meaning.

In Flutter, check each directional icon's matchTextDirection behavior. On the web, mirror with a logical class (for example [dir="rtl"] .icon-directional { transform: scaleX(-1); }) rather than editing each icon.

3. Mixed Arabic and English text (bidi)

Arabic interfaces constantly mix scripts: brand names, emails, product codes and numbers inside Arabic sentences. The Unicode bidirectional algorithm handles most of it, until a punctuation mark or a dynamic value lands at the edge of a phrase.

• Wrap dynamic values (user names, product names, order numbers) in an isolating element: HTML's bdi element, or dir="auto" on the container.
• In plain strings (notifications, SMS, native UI), wrap inserted values in Unicode isolates: FIRST STRONG ISOLATE (U+2068) before and POP DIRECTIONAL ISOLATE (U+2069) after. Libraries such as BidiFormatter on Android and in Dart's intl package do this for you.
• Use dir="auto" on inputs where users may type either language: search, chat, names, comments.
• Display and enter phone numbers, emails, URLs, IBANs and codes left-to-right, even inside an Arabic layout.
• Never build sentences by joining translated fragments ("You have" + count + "messages"). Use one translated template with placeholders, so the translator controls word order.
• Test sentences that end with an English word followed by punctuation; that is where the full stop usually jumps to the wrong side.

4. Numerals and number formatting

• Don't rely on locale defaults. They differ by locale and by runtime version: in a recent Node.js build, for example, Intl.NumberFormat('ar') outputs Western digits while 'ar-SA' and 'ar-EG' output Arabic-Indic digits. Set the numbering system explicitly, for example new Intl.NumberFormat('ar-SA', { numberingSystem: 'latn' }), or add -u-nu-latn to the locale tag.
• Remember the separators change too: Arabic-Indic formatting uses ٫ as the decimal separator and ٬ for thousands.
• Normalize digits on input. Users may type Arabic-Indic digits (٠-٩) or the Extended Arabic-Indic digits (۰-۹) found on some keyboards. Convert them to Western digits before validating, storing or calculating.
• Format currency deliberately: symbol or code (ر.س, SAR), position, and decimals per currency (the Kuwaiti, Bahraini and Omani currencies use three decimals).
• The Saudi riyal now has its own sign (approved in February 2025 and encoded in Unicode 17.0 as U+20C1). Many fonts don't include it yet, so check yours renders it before using it, or fall back to "ر.س" or "SAR".

5. Fonts and typography

• Use a typeface designed for Arabic, not the system fallback. Good free options on Google Fonts include Noto Sans Arabic, IBM Plex Sans Arabic, Cairo, Tajawal and Almarai. Pair it with a Latin font of similar weight and height.
• Arabic often looks smaller than Latin text at the same pixel size. Expect to increase the Arabic size slightly and give it more line height.
• Never apply letter-spacing to Arabic. Arabic letters join; spacing them apart breaks the script.
• Don't use italics or uppercase transforms for Arabic. Arabic has no true italic or capital letters; synthetic slanting looks wrong.
• Check the weights you use actually exist in the font, so the browser or OS doesn't fake bold.
• Leave room for diacritics (tashkeel) if your content uses them, as Quran, education and children's content does. Tight line heights clip the marks above and below letters. We built Lawh Academy, a Quran and Arabic learning app, where this matters on every screen.
• Subset web fonts to the Arabic and Latin ranges you need, to keep pages fast.
• Check text truncation: in RTL the ellipsis appears on the left side, and fixed-width labels need testing with long Arabic words.

6. Dates, times and calendars

• Decide where the Hijri calendar is needed. Saudi Arabia uses the Umm al-Qura calendar officially, and many users expect Hijri dates for HR, government-facing services, events and religious seasons. Set the calendar explicitly, for example with the locale tag ar-SA-u-ca-islamic-umalqura, rather than trusting the default, which has changed between runtime versions.
• Don't hard-code the first day of the week. Locale data puts it on Saturday for Egypt, Sunday for Saudi Arabia and Monday for the UAE. Use the locale's week information in calendars and date pickers.
• Know the weekend for booking and delivery logic: Friday and Saturday in Saudi Arabia, Egypt, Kuwait and Qatar; Saturday and Sunday for the UAE government and many UAE businesses.
• Use the right month names for the audience: Egypt and the Gulf commonly use يناير، فبراير, while the Levant and Iraq use كانون الثاني، شباط.
• Use ص and م for AM and PM, or a 24-hour clock where that is the norm.
• Relative times ("منذ 3 دقائق") need plural-aware formatting (see section 8).

7. Forms and input

• Put labels, required markers and error messages on the start side, and check their alignment in both directions.
• Keep phone, email, password, URL and card-number fields left-to-right, with the country code clearly placed.
• Use inputmode="numeric" for numeric fields and accept Arabic-Indic digits typed into them.
• Allow Arabic letters in validation. In JavaScript, a pattern like \p{Script=Arabic} with the u flag matches Arabic script; many "name" validators accidentally reject it.
• Don't force Western name structures. Arabic names often have several parts; a single "full name" field is often kinder than strict first/last fields.
• Make address forms flexible. Formats vary by country (Saudi Arabia has its national address system, for example), and many users describe locations by landmarks.

8. Search, sorting and copy

• Normalize Arabic for search: treat أ إ آ ا as the same letter, ة and ه, ى and ي; strip diacritics and the tatweel character (ـ). Otherwise users miss results for the "same" word.
• Sort with a locale-aware collator (Intl.Collator('ar') on the web) rather than by character code.
• Use professional translation by a native speaker, and choose one register (Modern Standard Arabic or a dialect) for the whole product.
• Support Arabic's six plural categories (zero, one, two, few, many, other) with ICU message formats or your framework's plural rules. "3 items" and "11 items" are worded differently in Arabic.
• Handle grammatical gender in second-person text, either with neutral phrasing or with gendered variants if you know the user's preference.
• Use Arabic punctuation: the comma ، the semicolon ؛ and the question mark ؟.
• Never put text inside images; you'll need a separate image for every language.

9. Beyond the screens

• Emails and push notifications: set dir="rtl" in Arabic email templates and test notification text with mixed content.
• PDFs and invoices: confirm your PDF library shapes Arabic correctly (connected letters, right order). Many don't by default.
• Search engines: give each language its own URL and connect them with hreflang alternates.
• App stores: write the Arabic listing natively and use Arabic screenshots for Arabic storefronts.
• Accessibility: with lang="ar" set, test screen readers (VoiceOver and TalkBack) in Arabic.

10. Testing

• Test with real Arabic content, not lorem ipsum or machine translation: long words, short labels, mixed sentences.
• Test on real phones with the system language set to Arabic, on both iOS and Android.
• Switch languages at runtime and check that nothing keeps the old direction.
• Take screenshots of key screens in both directions for every release, and compare.
• Have a native Arabic speaker review the product before launch. Most issues on this list are spotted in minutes by someone who reads Arabic every day.

The issues we fix most often

When teams ask us to fix an Arabic version, the same problems come up again and again: hard-coded left/right spacing that leaves the layout "almost" mirrored, arrows pointing the wrong way, phone numbers and prices scrambled inside Arabic sentences, Arabic falling back to a system font at the wrong size, and search that fails because the text isn't normalized. Sections 1 to 8 above cover each one.

Where to go from here

If you want this done for you, our Arabic and RTL localization service starts at $80 for RTL fixes on up to 5 pages or screens (about 2 days), $200 for a full RTL layout and Arabic font setup on up to 12 pages or screens (about 4 days), and $400 for a full bilingual setup with a language switch and translations wired in (about 6 days). For new products built Arabic-first, see Arabic app development. Choosing a framework? Our Flutter vs React Native comparison covers how each handles RTL. And for budgeting a Saudi product end to end, see app development cost in Saudi Arabia. You can also describe your project in our project planner.

FAQ

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

No. It flips text direction and flexbox layouts, but it doesn't fix hard-coded left/right spacing, icons, mixed text, numerals, fonts, dates or search. Those are where most Arabic bugs live, and this checklist covers them.

Should an Arabic app use Western or Arabic-Indic numerals?

It depends on your audience and brand. Both are common in the Arab world, and preferences vary by country and context. The mistake is mixing them: pick one per language, set it explicitly in your number and date formatting, and accept both when users type.

Which icons should be mirrored in RTL?

Icons that show direction or movement through a sequence, such as back and forward arrows, chevrons, undo and redo, and send icons. Don't mirror icons of real objects, logos, checkmarks, clocks or media playback controls.

Can I add Arabic to an existing English app later?

Yes, and we do it often, but it costs more than planning it from the start because every screen has to be checked. Fixing an existing product usually means replacing left/right values with start/end, sorting out icons and fonts, and wiring in translations.

What is the best Arabic font for an app?

There is no single best one. Choose a typeface designed for Arabic that has the weights you need and pairs well with your Latin font. Noto Sans Arabic, IBM Plex Sans Arabic, Cairo, Tajawal and Almarai are popular free options; test them with your real content at your real sizes.

Do I need separate URLs for Arabic and English pages?

For websites that should rank in search, yes. Give each language its own URL, link them with hreflang alternates, and set the lang and dir attributes correctly on each page.