RTL Web Design: How to Actually Build for Arabic and Hebrew

RTL web design means building a site so it works correctly when read right to left — the way Arabic and Hebrew are read — not just flipped to look right to left. Most sites serving Arabic or Hebrew speakers start as a left-to-right design that gets "translated," and translation alone leaves the underlying structure untouched: icons still point the wrong way, layout mirrors inconsistently between sections, dates and phone numbers break mid-sentence, and the type was never designed for the script it's now displaying. Done properly, RTL is a structural decision, not a content one — and it's the difference between a site that feels native to an Arabic or Hebrew reader and one that feels like an afterthought.

What "just translating" gets wrong

Swap the copy to Arabic or Hebrew and keep the same CSS, and you get a site that reads right to left but still behaves left to right underneath. Content boxes still float toward the original side, spacing that was hardcoded as margin-left or padding-right stays exactly where it was, and interactive elements — back buttons, form fields, breadcrumbs, sidebars — stay anchored to their original position while the surrounding text reverses. The result is a checkout flow where the "continue" button visually points backward, a search bar with the icon on the wrong end, and breadcrumbs that read in an order no RTL reader would expect. None of that is a translation problem — it's a layout problem that translation never touches.

Icons, arrows, and animations that point the wrong way

Any icon that implies direction needs to flip with the text: back and forward arrows, pagination chevrons, "next" buttons in a signup flow, and slide-in animations for menus or carousels. A back arrow that still points left in an Arabic interface is telling the reader to go the wrong way. But not everything should mirror — icons of objects with a fixed real-world orientation (a clock face, a camera, a play button, most logos) stay exactly as they are; mirroring those looks broken, not correct. Getting this distinction right takes a deliberate pass through every icon and transition in the product, not a global CSS flip.

• Should mirror: back/forward arrows, breadcrumbs, progress bars, carousel and slide-menu animations, chat bubble tails.
• Should NOT mirror: clocks, cameras, play/pause buttons, most brand logos, icons of real-world objects.

Numbers, dates, and mixed-direction text

Arabic and Hebrew text usually still displays numerals left to right even inside an otherwise right-to-left sentence, which means a phone number, price, or date embedded in a paragraph can visually scramble if the browser isn't told how to isolate it. Dates need to follow the reading order and format conventions of the language, not just have their digits swapped. Anything that mixes scripts — an English brand name inside an Arabic sentence, an email address, a product SKU — needs explicit direction handling (Unicode bidi isolation or the CSS unicode-bidi property), or punctuation and digits end up in the wrong order on screen even though the underlying text is correct.

Typography that wasn't built for Arabic or Hebrew

Reusing the Latin font at a "compatible" weight is the single most common shortcut, and it's usually the most visible mistake. Arabic is a connected, contextual script — each letter changes shape depending on its position in a word — and most Latin-first fonts either don't support Arabic at all or render it with cramped spacing, weak diacritic support, and a weight that doesn't visually match the Latin type sitting next to it. Hebrew has its own metrics too: different natural line height, no italic equivalent, and letterforms that read poorly at the same size a Latin font would use. Choosing typefaces actually designed for the script — with real Arabic OpenType support or Hebrew-specific weights — changes how a page feels more than any layout fix will.

Logical CSS properties: the fix that makes it stick

The lasting fix isn't a parallel RTL stylesheet maintained by hand — that approach rots the moment a new component ships and nobody remembers to mirror it. The fix is writing layout with CSS logical properties from the start: margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, text-align: start instead of text-align: left. Written this way, the browser flips the layout automatically the moment dir="rtl" is set on the page, and every new component inherits correct behavior by default instead of needing a manual RTL pass.

Why this matters commercially in a bilingual market

In a market where your audience reads Arabic or Hebrew alongside English, people notice within seconds whether a site was built for them or just translated at them. A mirrored icon, a scrambled date, or type that looks squeezed and foreign reads as unprofessional — even to fully bilingual users who could just switch to English instead. For e-commerce that shows up directly in checkout completion; for B2B it shows up in how seriously a prospect takes your product. Real RTL support isn't a nice-to-have for accessibility — it's a visible signal of how much a company actually invested in serving that market, and most competitors still haven't done it properly.