Arabic RTL Website Design: The Complete Guide | Blog

# Arabic RTL Website Design: The Complete Guide

TL;DR: Real Arabic RTL design isn't "flip the CSS" — it's dir="rtl" at the document root, CSS logical properties instead of left/right, an Arabic type stack that isn't Times New Roman, and manual handling for the numbers, phone numbers, and Latin brand names that stay left-to-right inside an RTL page.

If you sell into the UAE, most of your traffic is bilingual by default. Expatriates make up roughly 88% of the UAE's population of about 11.6 million, with large communities from India, Pakistan, Bangladesh, and the Philippines alongside Emirati Arabic speakers (Global Media Insight, UAE Population Statistics 2026). That means an Arabic site almost never runs Arabic-only — it runs Arabic and English, often on the same page, switched by a toggle. Getting that bilingual, bidirectional layer right is a genuinely narrow specialty. Most agencies handle it by mirroring a Bootstrap theme and calling it done, which is why so many "Arabic" government and e-commerce sites still have prices that read backwards or search icons on the wrong side.

This guide covers what actually breaks, and the real CSS, fonts, and testing approach to fix it.

Why "just flip the CSS" doesn't work

The naive approach to RTL is: take the English site, add direction: rtl, and let the browser mirror everything. That gets you maybe 60% of the way. Here's where it falls apart:

Mixed content is bidirectional, not just right-to-left. An Arabic paragraph containing a phone number, an email address, a Latin brand name, or an English product SKU has both RTL and LTR runs of text in the same line. The Unicode Bidirectional Algorithm (UBA) has to resolve the visual order of each run, and naive CSS mirroring doesn't touch this — it's a text-layer problem, not a layout-layer problem.
Icons and directional UI carry meaning. A "next" chevron, a back arrow, a progress bar, a slider — these need to visually reverse in RTL, but a search icon, a play button, or a company logo should not.
Physical CSS properties don't reverse themselves. margin-left: 16px stays on the left whether the page is RTL or LTR unless you explicitly handle it. This is the single biggest source of "translated but broken" bilingual sites.
Fonts behave differently. Most Latin webfonts have no Arabic glyphs at all — the browser silently falls back to a system font, which is why so many Arabic sites look like they're using a completely different (and worse) typeface than the English version.

The real CSS: logical properties, not left/right

The durable fix is CSS Logical Properties and Values — a W3C spec that lets you write margin-inline-start instead of margin-left, and have the browser resolve "start" and "end" based on the element's actual direction and writing-mode (MDN, padding-inline-start). Logical properties for padding and margin have solid cross-browser support today, so this isn't a bleeding-edge bet — it's the standard way to write direction-agnostic CSS in 2026.

Practical mapping:

Physical (LTR-only)	Logical (direction-aware)
`margin-left` / `margin-right`	`margin-inline-start` / `margin-inline-end`
`padding-left` / `padding-right`	`padding-inline-start` / `padding-inline-end`
`left: 0` / `right: 0`	`inset-inline-start: 0` / `inset-inline-end: 0`
`text-align: left`	`text-align: start`
`border-left`	`border-inline-start`
`float: left`	(avoid float for layout; use flex/grid with logical gap)

A few things worth calling out precisely, because they're where teams get burned:

1. Set `dir` on `<html>`, not just a wrapper `<div>`. The direction CSS property exists, but the HTML dir attribute is what browsers, screen readers, and the Unicode Bidi Algorithm actually key off — MDN's own guidance is to prefer the dir attribute over the CSS property wherever possible, because it keeps working even before/without CSS (MDN, `direction`). In a Next.js app this means setting dir={locale === 'ar' ? 'rtl' : 'ltr'} on the root <html> element in your layout, not buried on a content div three levels deep.

2. `unicode-bidi` matters for inline embeds. For the direction property to actually affect inline-level elements (a <span> inside a paragraph, for instance), unicode-bidi needs to be embed or override — plain direction: rtl on an inline element without this does nothing in some cases (MDN, `unicode-bidi`).

3. Isolate embedded LTR fragments with `<bdi>`. For dynamic content — a user's name, a product code, an English brand mentioned mid-Arabic-sentence — wrap it in <bdi> (bidirectional isolate). It stops that fragment's direction from leaking into and reordering the surrounding Arabic text, and it works even without CSS loaded (MDN, `<bdi>`).

4. `:dir()` is usable now — with a fallback. The :dir(rtl) / :dir(ltr) CSS pseudo-class is the correct direction-aware selector in spec terms, and it is no longer the risk it was: Firefox has supported it since version 17, Safari since 16.4, and Chrome and Edge since 120, putting global support at roughly 92% (Can I Use). If your baseline includes browsers older than Chrome 120, keep [dir="rtl"] attribute selectors as the fallback and treat :dir() as progressive enhancement; if it doesn't, you can use it directly (LogRocket, Exploring the CSS `:dir` pseudo-class).

5. Tooling exists so you don't hand-convert everything. If you're on a Tailwind stack, tailwindcss-logical swaps ml-4/pr-2 utilities for logical equivalents. If you're maintaining plain CSS or a design system, postcss-logical can transform logical properties into direction-specific fallbacks at build time for older browser support (npm, tailwindcss-logical; GitHub, postcss-logical).

Numbers are the trap almost everyone falls into

This is the detail that separates a genuinely bilingual UAE site from a mirrored one: Arabic script is RTL, but Arabic numerals (0–9) are still written and read left-to-right, even inside an RTL sentence. A price like "1,250 درهم" needs the digits 1,250 to stay in LTR order while the surrounding words flow RTL — the Unicode Bidi Algorithm generally handles this correctly for plain digit runs, but it breaks down around:

Phone numbers with formatting (+971 4 xxx xxxx) — the +, spaces, and hyphens can get visually reordered if the string isn't isolated with <bdi> or dir="ltr" on a <span>.
Mixed currency strings — "AED 4,500" vs. "4,500 درهم" need different digit/word ordering depending on which side the currency symbol is on, and CMS templates that concatenate strings naively will get this wrong per-locale.
Date formats — DD/MM/YYYY vs. the Hijri calendar (still used alongside Gregorian in UAE government and some commercial contexts) is a content decision, not just a CSS one; decide per-field whether you're localizing the calendar or just the language.
Eastern Arabic-Indic numerals (٠١٢٣٤٥٦٧٨٩) — some Gulf audiences expect these instead of Western digits in certain contexts (invoices, government forms); this is a content/locale decision your CMS needs to expose per-field, not a global font switch.

The fix in code is boring but essential: wrap standalone numeric/Latin fragments in <bdi> or a <span dir="ltr">, never trust string concatenation across locales for currency or phone formatting, and test every numeral-bearing component (pricing tables, forms, checkout) specifically in the Arabic locale — not just the marketing copy.

Font choices: what actually renders well

The failure mode here is subtle: a Latin font stack like font-family: 'Inter', sans-serif doesn't error on Arabic text — it just silently falls back to whatever Arabic font the visitor's OS ships, which varies wildly across Windows, macOS, iOS, and Android, and rarely matches your brand's Latin type weight or x-height. The fix is to explicitly declare a paired Arabic typeface, not just extend the fallback stack.

Solid, actively maintained options on Google Fonts as of 2026:

Cairo — a contemporary Arabic/Latin sans-serif designed for legibility, blending Latin sans-serif simplicity with naskh-style Arabic proportions. One of the most widely used Arabic UI fonts on the web today (Google Fonts / community roundup).
Tajawal — minimalist, geometric, multiple weights; a strong pick for app-like, modern brand interfaces (Google Fonts).
IBM Plex Sans Arabic — the Arabic extension of IBM's Plex system, designed by Mike Abbink/IBM BX&D with Bold Monday; the right call if your Latin brand type is already Plex, since weights and proportions are built to match (Google Fonts, IBM Plex Sans Arabic).
Noto Sans Arabic / Noto Kufi Arabic — part of Google's Noto family, built for broad script coverage and reliability; Noto Kufi Arabic is a clean, unmodulated Kufi style if you want something more geometric/display-oriented than a naskh-based body font (Google Fonts, Noto Kufi Arabic).

Practical rules for pairing:

1. Match x-height and weight, not just "looks similar." Arabic and Latin scripts have very different proportions; a bold Latin heading paired with a visually thin Arabic equivalent (even at the same declared font-weight) reads as broken hierarchy.

2. Load only the Arabic subset you need. Arabic webfont files are large if you include the full Unicode range; use unicode-range or a subset build to keep load times down, especially since mobile data costs and page-speed both factor into UAE audiences on 4G/5G.

3. Test line-height separately. Arabic diacritics and ligatures often need slightly more vertical breathing room than the Latin line-height you copy-pasted from the English stylesheet.

4. Never ship Arabic body copy in a purely Latin font stack — even as a "temporary" fallback. It's the single most common tell that a site was translated, not designed, for Arabic.

Layout and UX details that get missed

Navigation, breadcrumbs, and progress indicators must mirror. A checkout progress bar that fills right-to-left is correct in RTL; a mirrored back-arrow icon is correct; but a company logo, video play button, or the physical direction a person's face is looking in a photo should generally stay as designed — mirroring these can look broken or, in the case of photos, unintentionally comic.
Forms need RTL-aware validation messages and input alignment, including dir="rtl" on <input>/<textarea> elements themselves, not just their containers, so cursor position and placeholder text behave correctly.
Carousels and sliders should advance in the reading direction — "next" moves right-to-left in Arabic, which is the opposite of what a copy-pasted English carousel component does by default.
Tables need column order reversed, and this is one of the more error-prone areas because table layout tools built on physical left/right styling (rather than logical properties or [dir]-aware CSS) often only mirror the text, not the column order.

Where this fits with UAE compliance and data rules

Two regulatory facts are worth knowing if you're scoping a bilingual UAE site with forms, checkout, or user accounts — they're not RTL-specific, but they shape what you build alongside the Arabic layer:

VAT stays at the standard 5% rate. UAE VAT has been 5% since introduction in 2018 and remains 5% in 2026; note that supplier-verification and e-invoicing rule changes took effect from January 2026, which affects checkout and invoice templates more than the rate itself (Daftra, VAT in UAE 2026).
Personal data is governed by Federal Decree-Law No. 45 of 2021 (PDPL), in effect since January 2, 2022, which applies UAE-wide (excluding free zones) and has extraterritorial reach to any controller/processor handling UAE residents' data — similar in structure to GDPR (Securiti, Overview of UAE PDPL). If your site or a section of it sits in a free zone like DIFC, note that DIFC runs its own Data Protection Law No. 5 of 2020, a separate GDPR-aligned regime enforced by its own regulator — mainland-to-DIFC data transfers are technically cross-border transfers, which matters if your bilingual site's backend, CRM, or hosting spans both (PrivacyEngine, Federal PDPL vs DIFC & ADGM). Consent language, privacy policy pages, and cookie banners should be fully and separately localized in Arabic — not machine-translated — since consent has to be genuinely informed in the language the user is reading.

A short testing checklist

Before calling a bilingual UAE site done, check each of these specifically in the ar locale, not just visually skim the English version:

[ ] <html dir="rtl" lang="ar"> set at the root, not on a wrapper div
[ ] Every margin-left/right, padding-left/right, left/right position rewritten as a logical property
[ ] Phone numbers, prices, and dates render with correct digit order (test a real UAE phone number and an AED price string)
[ ] Arabic font pairing loads and matches Latin weight/x-height — inspect computed font-family, don't trust the design mockup
[ ] Icons that carry directional meaning (arrows, chevrons, progress) are mirrored; brand/photo assets are not
[ ] Forms: input dir, validation message alignment, and placeholder text all behave correctly
[ ] Carousels/sliders advance right-to-left
[ ] Privacy policy, consent banner, and checkout copy are professionally localized, not machine-translated

This is exactly the kind of detail-level work our UI/UX design team handles for UAE clients running bilingual sites — not a mirrored theme, but a layout and typography system that's actually designed for Arabic from the component level up.

FAQ

Does `direction: rtl` in CSS do everything I need for an Arabic site?

No. It flips block-level layout, but it doesn't fix physical left/right properties you've hardcoded elsewhere, doesn't handle bidirectional text (numbers, phone numbers, Latin brand names inside Arabic copy), and doesn't touch font selection. You need dir="rtl" on <html>, logical CSS properties throughout, <bdi> isolation for embedded LTR fragments, and an Arabic-specific font stack.

Can I just use Google Translate on my English site to get an Arabic version?

For a real business site, no. Machine translation misses register, misreads bidirectional numeral/currency strings, and — critically for anything involving consent, privacy policies, or checkout — needs to be genuinely understood by the reader, not approximately correct. Professional Arabic copywriting, paired with a properly built RTL layout, is what actually converts.

What's the difference between UAE's federal PDPL and a free zone data law like DIFC's?

The federal PDPL (Federal Decree-Law No. 45 of 2021) applies across the UAE mainland; DIFC and other free zones run their own separate, GDPR-aligned data protection regimes with their own regulators. If your site's infrastructure or user base spans both onshore UAE and a free zone, you may need to comply with both, and data moving between them counts as a cross-border transfer.

Which Arabic web font should I use if I don't know where to start?

Cairo and Tajawal are both solid, widely used, actively maintained choices on Google Fonts with good weight ranges for UI work. If your Latin brand font is already IBM Plex, use IBM Plex Sans Arabic for a matched pairing. Avoid shipping Arabic body text in a Latin-only font stack and letting the OS silently substitute a fallback — declare the Arabic family explicitly.