Supporting right-to-left languages does not mean maintaining a second stylesheet. Learn how CSS logical properties, the dir attribute, and a few Tailwind patterns let one codebase mirror itself correctly for Arabic, Hebrew, Persian, and Urdu.
Arabic (ar), Hebrew (he), Persian (fa), and Urdu (ur), identified by their BCP 47 locale codes, are read right to left, and together they cover well over half a billion people. Arabic alone is one of the most widely spoken languages in the world, and markets such as the Gulf states are an increasingly common target for SaaS products.
RTL still gets deferred on most roadmaps, because the received wisdom is that it means a second stylesheet, a build-time flipping step, and a permanent maintenance tax. That was accurate around 2015. It is not accurate now. With CSS logical properties -- supported in every current browser -- the browser does the mirroring for you, and the work becomes a mostly mechanical find-and-replace plus a handful of genuine judgment calls.
Everything downstream depends on one attribute:
<html lang="ar" dir="rtl">
Set it server-side from the active locale (if you are on Next.js, the [locale] layout from our next-intl setup guide is the natural place). Two reasons not to do it in a useEffect: the first paint renders in the wrong direction and visibly flips, and any server-rendered HTML you send is wrong until hydration.
// app/[locale]/layout.tsx
const RTL_LOCALES = ["ar", "he", "fa", "ur"];
export default async function Layout({ children, params }) {
const { locale } = await params;
const dir = RTL_LOCALES.includes(locale) ? "rtl" : "ltr";
return (
<html lang={locale} dir={dir}>
<body>{children}</body>
</html>
);
}
Setting dir alone already fixes text alignment, the direction text flows within a paragraph, and the default order of inline elements. It does not fix any layout you pinned with left, right, margin-left, or padding-right. That is step two.
CSS has two coordinate systems. Physical properties (left, right, top, bottom) refer to the screen. Logical properties refer to the text flow: the inline axis runs in the reading direction, the block axis runs down the page. In an LTR document inline-start resolves to left; in an RTL document it resolves to right. Same CSS, mirrored result.
| Physical | Logical |
|---|---|
| margin-left / margin-right | margin-inline-start / margin-inline-end |
| padding-left / padding-right | padding-inline-start / padding-inline-end |
| left / right | inset-inline-start / inset-inline-end |
| border-left | border-inline-start |
| text-align: left / right | text-align: start / end |
| border-radius corners | border-start-start-radius, etc. |
| width / height | inline-size / block-size |
A concrete before and after -- a sidebar with a left border and an offset icon:
/* Before -- breaks in RTL */
.callout {
border-left: 3px solid var(--accent);
padding-left: 1rem;
margin-left: 2rem;
text-align: left;
}
/* After -- mirrors automatically */
.callout {
border-inline-start: 3px solid var(--accent);
padding-inline-start: 1rem;
margin-inline-start: 2rem;
text-align: start;
}
Note that margin-block and padding-block exist too, but vertical values do not change under RTL -- so converting them is stylistic consistency, not a bug fix. Prioritize the inline axis.
Tailwind v3.3+ ships logical utilities and they are drop-in replacements:
ml-4 -> ms-4 (margin-inline-start)
mr-4 -> me-4 (margin-inline-end)
pl-6 -> ps-6 (padding-inline-start)
pr-6 -> pe-6 (padding-inline-end)
left-0 -> start-0
right-0 -> end-0
text-left -> text-start
text-right -> text-end
border-l -> border-s
For the rare case that genuinely needs direction-specific styling, Tailwind also has rtl: and ltr: variants:
<ChevronRight className="rtl:rotate-180" />Use those variants sparingly. Every one is a place where the two directions can drift apart. If you find yourself writing more than a handful, the underlying layout probably still uses physical properties.
Mirroring is not universal, and over-mirroring looks just as broken as under-mirroring.
Arabic text containing a phone number, a version string, or an English product name uses the Unicode bidirectional algorithm to lay out those runs left to right inside a right-to-left paragraph. The browser handles this for you as long as you do not fight it. Where it goes wrong is user-generated content that mixes scripts -- wrap untrusted mixed content in an element with dir="auto" so the browser infers direction from the first strong character. Mixed-script strings bring other traps too, covered in Unicode string bugs that break i18n.
Code is always LTR, in every locale. Force it:
pre, code, kbd, samp {
direction: ltr;
text-align: left;
}Forgetting this produces right-aligned, visually reordered code samples that are genuinely unreadable.
The usable rule: if the icon means "that way," mirror it. If it depicts a thing, leave it.
A progress bar filling from the left in an RTL interface reads as emptying. Anchor fills and animations to inset-inline-start. Chart axes are a real design decision -- many RTL products keep time-series charts running left to right because the convention is borrowed from math, but menus, steppers, and timelines should follow the reading order.
Arabic and Hebrew are not just LTR text pointed the other way. Practical notes:
line-height of 1.5 that looks fine in Latin often looks cramped in Arabic; 1.7-1.8 reads better.text-transform: uppercase is a no-op and synthetic italics look wrong. Use weight and color for emphasis instead.You do not need a translator to catch layout bugs. Force the direction and look at the page:
// In devtools console -- instant RTL preview of any page
document.documentElement.dir = "rtl";What to look for: elements that did not move when everything else did. A misaligned close button, a dropdown that opens off-screen, an avatar still pinned to the left of a right-aligned name, a tooltip arrow pointing at nothing. Each one is a physical property you missed.
Worth adding to CI: a couple of visual regression snapshots taken with dir="rtl", plus a lint rule banning margin-left, padding-right, and friends in new CSS. Preventing regressions is much cheaper than a second audit in six months. A pseudo-locale that also flips direction lets you run the same checks on every pull request.
Set dir="rtl" on the html element for right-to-left locales and replace directional CSS properties with logical equivalents, such as margin-inline-start instead of margin-left and text-align: start instead of text-align: left. The browser then mirrors the layout automatically without a second stylesheet.
Logical properties describe position relative to text flow rather than to the screen. The inline axis follows the reading direction, so inline-start resolves to left in a left-to-right document and to right in a right-to-left one, letting the same CSS serve both directions.
Mirror icons that indicate direction, such as back and forward arrows, next and previous chevrons, undo and redo, and send arrows. Do not mirror icons that depict objects, such as clocks, checkmarks, magnifying glasses, logos, or media play buttons.
Yes. Tailwind provides logical utilities such as ms-4, me-4, ps-6, pe-6, start-0, end-0, and text-start that map to CSS logical properties, plus rtl: and ltr: variants for the rare cases that genuinely need direction-specific styling.
Run document.documentElement.dir = "rtl" in the browser console to flip any page instantly. Then look for elements that did not move with the rest of the layout, such as misaligned close buttons, off-screen dropdowns, or tooltip arrows pointing at nothing.
RTL is a one-time conversion, not an ongoing second codebase. Set dir on the html element from the locale, convert physical CSS properties to logical ones, explicitly pin code blocks to LTR, mirror only the icons that indicate direction, and give Arabic proper fonts and line height. After that, adding Hebrew or Persian is only a translation task.
And once the layout mirrors correctly, shipping Arabic becomes a content problem rather than an engineering one -- which is where Babelize fits, keeping your RTL locale files in sync with every new string you add instead of letting Arabic fall three releases behind English.
--- - [All articles](https://www.babelize.co/blogs)