Arabic Website Design in Dubai: RTL Guide (2026)
A practical guide to Arabic RTL website design in Dubai: what should never mirror, typography rules, CSS logical properties, and bilingual SEO.
Open the Arabic version of most Dubai business websites and you can usually tell within three seconds that it wasn't actually designed — it was translated. The icons are mirrored (including the ones that shouldn't be), the line spacing is too tight to read comfortably, the copy reads like it passed through a machine because it did, and somewhere on the page a phone number or a percentage is displayed backwards. None of this is because the business doesn't care about its Arabic-speaking customers. It's because "add an Arabic version" gets treated as a translation task bolted onto a finished English site, rather than a real design and engineering decision made from day one.
Short answer: A genuine Arabic website isn't your English site with dir="rtl" switched on and Google Translate run over the copy. It requires independently authored Arabic content (not translated word-for-word), CSS built with logical properties instead of hardcoded left/right values, typography rules specific to Arabic script, a clear list of elements that should never mirror, and a routing and hreflang architecture that tells Google these are two first-class experiences rather than one page pretending to be two. Skipping any of these produces the mirrored-icons, awkward-copy result most people have learned to associate with "the Arabic version" — and in the UAE, where Arabic speakers are a primary audience for enormous parts of the economy, that's not a cosmetic problem, it's a business one.
What "RTL Website Design" Actually Means
Right-to-left (RTL) design starts with the dir="rtl" HTML attribute, which tells the browser that text, reading order, and — if your CSS is written correctly — layout flow should run from right to left instead of left to right. That single attribute does a lot of work automatically: text alignment, the default direction of flexbox and grid layouts, and scrollbar position all flip based on it in a properly built site.
The mistake most teams make is assuming dir="rtl" handles everything, then discovering it doesn't, and "fixing" the gaps with a blunt CSS transform or manually flipped positioning rules. That approach creates a second, parallel stylesheet you now have to maintain forever, and it's exactly how you end up mirroring things that were never supposed to mirror in the first place.
The Mirroring Myth: What Should Never Flip
This is the single most common technical mistake in Arabic website builds, and it's worth being explicit about because it's counterintuitive: not everything reverses in RTL, even though the reading direction does.
Numerals stay left-to-right. Whether you're using Western numerals (123) or Eastern Arabic numerals (١٢٣), numbers are read left-to-right even inside an RTL sentence. A price of "250 AED" or a phone number should never have its digit order reversed, even though the surrounding Arabic text flows right-to-left.
Media controls don't mirror. Video and audio player controls — play buttons, scrubbers, volume sliders — follow a left-to-right time convention almost universally, regardless of the site's text direction. Mirroring a video scrubber so it plays from right to left confuses users rather than helping them.
Phone numbers, emails, and code snippets stay put. Anything that's fundamentally a left-to-right token — a phone number, an email address, a URL, a piece of code — should be wrapped so it renders left-to-right even inside RTL body text, otherwise it becomes unreadable or, in the case of phone numbers, potentially wrong.
Directional icons need judgment, not defaults. An arrow pointing toward "next" or "forward" should usually flip to point left in RTL, because it represents a direction of progress that reverses with reading order. A play button, a checkmark, or a settings gear icon shouldn't flip, because they're not directional in that sense. Getting this list right is a design decision, not something you can automate by mirroring everything and calling it done.
Typography Rules That Make or Break Arabic Legibility
Typography is where a huge share of Arabic websites quietly fail, because the mistake doesn't look broken the way a flipped phone number does — it just looks slightly uncomfortable to read, and most non-Arabic-speaking stakeholders never notice.
Line height needs more room than Latin text. Arabic script has more vertical complexity than Latin script — connecting letterforms, diacritical marks in some contexts, and taller ascenders and descenders in certain letter combinations. A line-height setting that looks perfectly comfortable for English body copy (commonly around 1.4–1.5) frequently causes Arabic lines to visually crowd or overlap. Arabic body text generally needs a taller line-height than the Latin equivalent on the same page.
Font pairing is a real design decision, not an afterthought. Choosing one typeface family that happens to ship with both Latin and Arabic glyphs, or hand-picking a geometric, modern Arabic typeface to pair with your existing Latin brand font, produces a dramatically more polished result than letting the browser fall back to a default system Arabic font it was never designed to sit next to. A mismatched pairing — a warm, humanist Latin font next to a heavy, traditional Arabic face — creates visual dissonance even to readers who can't articulate why the page feels off.
Letter-spacing tricks that work in Latin text actively break Arabic. Arabic is a cursive, connected script — letters join to their neighbors and change shape depending on their position in a word. Adding letter-spacing (tracking) to Arabic text, a common technique for stylistic emphasis in Latin typography, breaks the letter connections and can render words illegible. If your design system applies letter-spacing globally, it needs an explicit override for Arabic locales.
The Technical Foundation: How to Actually Build This
The durable way to handle RTL isn't a parallel "mirrored" stylesheet — it's building the entire site with CSS logical properties from the start, so the browser handles directional flipping automatically based on the page's dir attribute.
Instead of margin-left and margin-right, logical properties use margin-inline-start and margin-inline-end — "start" and "end" resolve to left and right automatically depending on the text direction. The same pattern applies to padding-inline-start/end, border-inline-start/end, and using text-align: start instead of hardcoding text-align: left. Written this way, a single stylesheet correctly serves both the English and Arabic versions of the site without a second RTL-specific override file to keep in sync forever — the browser does the mirroring work that a component-by-component manual approach would otherwise require.
On the routing side, this is one of the areas where genuine architecture decisions matter more than most businesses realize. NxFold's own site is built on Next.js with the next-intl internationalization library, using an "as-needed" locale prefix strategy: the English site lives at the root domain path structure (no /en/ prefix cluttering every URL), while Arabic pages live under a clean /ar/ prefix — nxfold.com/blog/... for English, nxfold.com/ar/blog/... for Arabic. That's a deliberate structural choice, not an accident: it keeps English URLs clean (since English is the default/primary locale for this particular audience mix) while giving Arabic its own fully separate, crawlable URL tree that Google can index as a distinct language version.
Alongside the URL structure, every page needs hreflang tags declaring the relationship between language versions: an en-AE tag on the English page pointing to itself, an ar-AE tag pointing to the Arabic equivalent, and an x-default tag indicating the fallback version for users whose language doesn't match either. Get this wrong — or skip it entirely, which is extremely common — and Google may show the wrong language version to searchers, or treat the two language versions as duplicate content instead of intentional locale variants.
Content Strategy: Why Translation Isn't Localization
This is the point where most "we added an Arabic version" projects quietly go wrong, and it happens at the content layer rather than the visual one, which is why it's harder to notice in a design review.
Literal translation reads like a translation. Idioms, sentence rhythm, and persuasive structure don't survive word-for-word translation between English and Arabic. A headline that works as punchy, confident English often becomes stilted or overly formal when translated literally, and a call-to-action that feels natural in English can feel oddly aggressive or oddly passive once translated without adjustment for how Arabic-speaking audiences actually expect that kind of message to be phrased.
Arabic keyword research has to be done independently, not translated from English keywords. Search behavior in Arabic doesn't mirror English search behavior one-for-one. Gulf Arabic speakers frequently search using a mix of Modern Standard Arabic and colloquial Gulf-dialect terms, sometimes within the same query, and the exact phrasing that ranks well in English (say, "website development company Dubai") doesn't automatically map to the highest-volume or highest-intent Arabic phrasing for the same underlying need. Running English keywords through a translator and using the output as your Arabic SEO strategy consistently underperforms compared to independent Arabic-language keyword research.
Imagery and examples need a regional lens, not just a language swap. Stock photography, example use cases, and cultural references that resonate with an English-reading, often more international audience don't automatically resonate the same way with a Gulf Arabic-reading audience, even when the surrounding copy is well translated. Genuinely localized content adjusts these choices deliberately rather than reusing the English version's imagery unchanged.
SEO for Bilingual Arabic/English Sites
Beyond hreflang tags, there's a structural decision every bilingual UAE business has to make: where does the Arabic content actually live?
| URL structure | What it looks like | Best fit |
|---|---|---|
| Subdirectory | nxfold.com/ar/blog/... | Most UAE SMBs and mid-market businesses — consolidates domain authority across both languages, simplest to maintain, easiest for one team to manage |
| Subdomain | ar.nxfold.com/blog/... | Larger organizations running genuinely separate teams or CMS platforms per language, where operational separation matters more than consolidated authority |
| Separate ccTLD | A distinct .ae or country-specific domain per language | Enterprises with dedicated regional legal entities or marketing budgets per country — rarely justified for a single-market UAE business |
For the overwhelming majority of UAE businesses building a bilingual site, a subdirectory structure with correct hreflang implementation is the right call: it keeps all the SEO authority your content earns concentrated on one domain instead of splitting it across subdomains that Google may treat as semi-independent properties, and it's dramatically simpler to maintain with a single content team and a single deployment pipeline.
The UAE Is Raising the Bar on Arabic Digital Presence
There's a regulatory signal worth knowing about if you're deciding whether a "good enough" Arabic version is acceptable for now: the UAE has been drafting a new Arabic Language Law, with the feasibility study submitted for Cabinet approval and a targeted introduction around 2027. The draft explicitly covers ten sectors, including "technology and digitisation," and calls for integrating Arabic into digital platforms and AI systems specifically — not just formal government documents.
This is a draft, not an enforced regulation yet, and the specifics of any digital-platform requirements for private businesses aren't finalized. But the direction is clear enough that it's worth treating as a planning signal rather than a surprise to react to later: businesses that already have a genuinely well-built, independently authored Arabic presence won't be scrambling to retrofit one under a deadline, while businesses running a machine-translated afterthought version will have considerably more rework ahead of them if formal requirements do land in the sectors this draft names.
Common Mistakes in Arabic Website Projects
Relying on a Google Translate widget instead of real content. An embedded auto-translate widget is not the same thing as a localized Arabic website — it doesn't get indexed as genuine Arabic content by search engines in the same way, it can't be edited or refined by a copywriter, and the translation quality is exactly what you'd expect from unsupervised machine translation of marketing copy.
Mirroring elements that were never supposed to mirror. Reversed phone numbers, backwards percentages, and flipped video scrubbers are the most visible signal that a site's RTL implementation wasn't tested carefully — and they're some of the first things an Arabic-speaking visitor notices.
Treating Arabic as a design pass that happens after the English design is finalized. When Arabic typography, line-height, and content length aren't considered until after the English layout is locked, the Arabic version ends up cramped into a grid that was never built to accommodate it — Arabic text is frequently longer or shorter than its English equivalent for the same meaning, and a rigid, English-first layout doesn't flex to absorb that difference gracefully.
Skipping hreflang tags entirely. This is extremely common and quietly damaging: without hreflang, Google has to guess which language version to show which searcher, and it frequently guesses wrong, or treats both versions as competing for the same search results instead of serving the correct one to the correct audience.
Using directly translated keywords instead of independent Arabic keyword research. Covered above, but worth repeating as a standalone mistake because it's so common: it consistently leaves real search volume and real customer intent undiscovered.
What a Genuine Bilingual Build Actually Involves
A properly built bilingual Arabic/English website is meaningfully more work than an English site with a translated copy — not because the technology is exotic, but because the content and QA effort roughly doubles rather than being a translation pass at the end. Independent Arabic copywriting (not translation), Arabic-specific typography and line-height tuning, a full RTL layout QA pass checking every component in both directions, independent Arabic keyword research, and hreflang/routing implementation are all genuine additional work items, not optional polish.
This is the same build-vs-buy honesty that applies to custom software development in Dubai more broadly: a template with an Arabic translation plugin bolted on is cheaper and faster, and it's the right choice for a business that genuinely doesn't depend on its Arabic-speaking audience converting well. A business where Arabic-speaking customers are a primary revenue source — which describes a large share of the UAE market — is better served treating the Arabic build as a first-class part of the project scope from day one, the same way how much a website actually costs in Dubai depends heavily on scope decisions made upfront rather than added later.
Testing Checklist for RTL Sites
Before calling an Arabic version done, it's worth deliberately testing rather than assuming the English QA pass covers it:
- Forms and inputs — do text fields, placeholder text, and validation error messages align and read correctly in RTL, including where the cursor lands when a user starts typing?
- Date and number formatting — are dates, prices, and numerals displaying in the expected order and format for the locale, not silently reversed?
- Dropdowns and select menus — do they open and align in the correct direction, and does the chevron/arrow icon point the right way?
- Icons with directional meaning — arrows, back/forward buttons, and progress indicators specifically, checked one by one rather than assumed correct because the rest of the mirror worked
- Mobile gesture behavior — if the site or an associated app uses swipe gestures, are they inverted appropriately for RTL, matching what an Arabic-reading user expects from "next" and "back" swipes?
- Font rendering across browsers and devices — Arabic font rendering, particularly letter-joining behavior, can vary across browsers and operating systems in ways Latin text rarely does, so it's worth checking on more than one platform.
Frequently Asked Questions
What is RTL website design?
RTL (right-to-left) website design is building a site so that text, reading order, and layout flow from right to left, matching how Arabic (and other RTL languages) are read — done properly with CSS logical properties and the dir="rtl" HTML attribute rather than manually mirrored styles.
Is machine-translated Arabic content bad for SEO? Yes, generally. Machine-translated content tends to read unnaturally, doesn't reflect how Arabic speakers actually phrase search queries, and can underperform independently written, keyword-researched Arabic content in both rankings and conversion.
Should every element mirror in RTL design? No. Numerals, phone numbers, media player controls, and non-directional icons should stay in their original left-to-right orientation even within an RTL layout. Only genuinely directional elements — like "next" arrows — should flip.
Should Arabic content live on a subdirectory, subdomain, or separate domain?
For the large majority of UAE businesses, a subdirectory (like /ar/) with correct hreflang tags is the right structure — it consolidates SEO authority on one domain and is simplest to maintain. Subdomains or separate ccTLDs are usually only justified for larger organizations with genuinely separate regional operations.
What fonts work best for Arabic websites? Geometric, modern Arabic typefaces paired deliberately with a complementary Latin font typically outperform relying on a default system Arabic fallback font, both for legibility and for brand consistency between the English and Arabic versions of a site.
Does UAE law require businesses to have Arabic websites? Not yet in a fully enforced, digital-platform-specific way, but the UAE has been drafting a new Arabic Language Law — covering ten sectors including technology and digitisation, with integration of Arabic into digital platforms named explicitly — with an expected introduction around 2027. It's a signal worth planning around rather than a current binding requirement for private-sector websites.
How much does a proper bilingual website cost in Dubai? It depends heavily on scope, the same way any custom build does — a genuinely independent Arabic content pass, RTL-specific design and QA, and hreflang/routing implementation add real cost over an English-only site or a translated afterthought, but the added cost is generally far smaller than the cost of losing conversions from a market where Arabic-speaking customers are a primary audience.
Can an existing English-only site be converted to bilingual later?
Yes, but it's meaningfully more work than building bilingual from the start, particularly if the original CSS wasn't written with logical properties — retrofitting RTL support onto a codebase full of hardcoded margin-left/margin-right values means auditing and rewriting styles component by component rather than getting the behavior automatically.
The Bottom Line
A real Arabic website isn't a translated copy of your English site with the text flipped — it's independently authored content, typography tuned for Arabic legibility, CSS built with logical properties so mirroring happens automatically and correctly, a clear list of elements that should never flip, and a routing and hreflang structure that tells Google these are two genuine language versions. Given how central Arabic-speaking customers are to large parts of the UAE market, and given that formal expectations around Arabic digital presence appear to be tightening rather than loosening, treating the Arabic version as equal in priority to the English one from day one is the cheaper option in the long run, not the more expensive one. If your current Arabic site is a translated afterthought and you want to know what fixing it properly would actually involve, talk to NxFold — we build genuinely bilingual EN/AR platforms as standard practice, not as an add-on service, and can walk through exactly what a real RTL rebuild would cover for your specific site.