RTL Email Design: Why It's More Than text-align: right
The most common mistake in right-to-left (RTL) email is treating it as a text problem. You add `text-align: right`, ship it, and assume Arabic, Hebrew, Persian, or Urdu readers are taken care of. They aren't. RTL is a *layout direction*, not a text alignment — it flips the entire reading axis of the message. The logo that anchored the top-left now belongs top-right. The progress arrow that pointed forward now points the other way. Numbers and Latin brand names embedded mid-sentence can scramble into nonsense if you don't isolate them. Getting RTL right means rebuilding the visual hierarchy around a mirrored axis, not nudging one CSS property. This guide walks through what actually changes — `dir="rtl"` at the document level, mirroring the layout, bidirectional (bidi) isolation with `<bdi>`, and CSS logical properties — and is honest about where tooling helps and where it doesn't. BuilderJS, the embeddable editor, ships RTL support and i18n for 20+ locales in the builder chrome and lets authors set content direction; it does not translate your copy. Knowing that line keeps your RTL email both correct and your expectations realistic.
Start at the root: dir="rtl" on the document, not the cell
RTL begins with one declaration that governs everything beneath it. Set `dir="rtl"` on the `<html>` element (and, for resilient email, on `<body>` and your outermost layout table too, since some clients strip or ignore root attributes). That single attribute does far more than `text-align: right`: it tells the rendering engine the *base direction* of the document, which controls how inline content flows, how list bullets and blockquote bars sit, how the bidirectional algorithm resolves mixed text, and the default alignment of every block. `text-align: right` only pushes glyphs to the right edge of their box — it leaves the box itself, and the reading order of mixed content, in left-to-right (LTR) mode. The difference shows the moment you have a bulleted list (bullets jump to the right), a quote, or an Arabic sentence containing an English word. Because Outlook on Windows renders through Microsoft's Word engine and many clients table-ize your layout, apply `dir="rtl"` at the table and cell level as well, not just the document root, so the direction survives client sanitizing. Direction is structural; alignment is cosmetic. Set the structure first.
Mirror the visual hierarchy, don't just flip the text
This is the part teams skip, and it's the part readers notice. In an RTL email the eye enters from the top-right and travels right-to-left, so the *composition* must mirror to match. The brand logo moves from top-left to top-right. A two-column "image left, text right" row should usually become "image right, text left," so the reading order stays natural. Directional iconography flips: a "next" chevron, a back arrow, a step-by-step progress bar, a quote mark — all should point the RTL way, or they'll read as pointing backward. Padding and indentation that created a left margin for emphasis now need to create a right margin. Even a call-to-action button that sat bottom-right of a card may read better bottom-left once the axis flips. The trap is mirroring the text while leaving the scaffolding in its LTR positions, producing a hybrid that feels subtly wrong — text reading one way, the eye-path furniture pointing the other. Treat RTL as a layout pass over the whole template: walk every directional element and ask "does this still lead the eye correctly when reading right-to-left?" Note that not everything should mirror — logos with embedded Latin wordmarks, photographs, and most numeric data stay as-is. Mirror the *flow*, not the *content*.
Isolate mixed-direction text with <bdi> and the bidi algorithm
The nastiest RTL bugs come from mixing scripts: an Arabic sentence with an English brand name, a Hebrew label next to a phone number, a price with a currency code. Browsers and email clients resolve this with the Unicode Bidirectional Algorithm, which is good but not telepathic — neutral characters like spaces, parentheses, slashes, and punctuation get pulled toward whichever direction wins the tug-of-war around them. The classic failure: a username or order number rendered next to RTL text comes out with its digits or its trailing punctuation in the wrong place, e.g. "(2024" instead of "2024)". The fix is *isolation*. Wrap each foreign-direction run in `<bdi>` (bidirectional isolate), which tells the algorithm to treat that span's directionality independently of its surroundings — so a Latin brand name embedded in Arabic copy renders cleanly without leaking direction into the neighboring text. For finer control there's `dir="auto"` (let the engine infer from the first strong character, useful for user-generated names) and the CSS `unicode-bidi: isolate` / `bidi-override` family. The practical rule for email: wrap Latin brand names, numbers, URLs, and any user-supplied string sitting inside RTL copy in `<bdi>`. It's the single highest-leverage habit for correct mixed-direction email, and it costs you one tag.
Use CSS logical properties so one stylesheet serves both directions
Physical CSS properties — `margin-left`, `padding-right`, `left`, `border-left` — are hard-coded to a side of the screen and don't flip when direction does. Maintaining an RTL email by hand-swapping every `left` for `right` is exactly the error-prone busywork that breaks on the next edit. CSS *logical* properties solve this by naming sides relative to the reading direction instead of the screen: `margin-inline-start` is the leading edge (left in LTR, right in RTL), `margin-inline-end` is the trailing edge, and `padding-inline`, `border-inline-start`, and `inset-inline` work the same way. Write your spacing once with logical properties, set `dir` on the root, and the same rules produce correct LTR and RTL output — the leading margin lands on the correct side automatically. The honest caveat for email specifically: logical-property support across email clients lags the web, and Outlook's Word-based desktop engine in particular is unreliable here, so robust email still leans on `dir` plus direction-aware table structure and inline styles as the dependable base, with logical properties layered on where supported. (For why email forces inline CSS at all, see the inline-CSS guide linked from the email hub.) Use logical properties to stay maintainable, but test the rendered output — RTL email lives or dies on real-client checking, not on theory.
Frequently asked questions
-
Isn't RTL email just text-align: right plus a translation?
No — those are the two things people assume cover it, and neither does. `text-align: right` only moves glyphs to the right edge of their box; it leaves the box layout, list markers, and mixed-text reading order in LTR mode. True RTL means setting `dir="rtl"` at the document and table level, mirroring the visual hierarchy (logo, columns, directional icons), and isolating mixed-direction runs. Translation is a separate concern entirely — direction is structural and must be set even before any words are translated.
-
What does <bdi> do and when do I need it?
`<bdi>` (bidirectional isolate) wraps a run of text whose direction differs from its surroundings — typically a Latin brand name, number, URL, or user-supplied string sitting inside Arabic or Hebrew copy — and tells the Unicode Bidirectional Algorithm to resolve that span independently. Without it, neutral characters like spaces, parentheses, and punctuation get pulled the wrong way, so digits or trailing brackets land out of place. The practical rule: in RTL email, wrap Latin names, numbers, and dynamic values in `<bdi>`. It's the highest-value, lowest-cost habit for correct mixed-direction text.
-
Should CSS logical properties replace margin-left and padding-right in email?
Use them where you can, but don't rely on them alone for email. Logical properties (`margin-inline-start`, `padding-inline`, `border-inline-start`, `inset-inline`) name sides relative to reading direction, so a single stylesheet serves both LTR and RTL once `dir` is set — far more maintainable than hand-swapping `left` and `right`. The caveat is that email-client support lags the web, and Outlook's Word-based desktop engine is unreliable here. Robust RTL email leans on `dir` plus direction-aware table structure and inline styles as the dependable base, with logical properties layered on top, then tests the real rendered output.
-
Does BuilderJS automatically translate my email into Arabic or Hebrew?
No, and this is an important scope line. BuilderJS provides built-in RTL support and i18n for 20+ locales in the editor chrome (the builder's own interface) and lets authors set the direction of the content they create. It does not translate your copy — the words you type or import are yours to write or localize. The editor handles the direction; you bring the language. BuilderJS is the embeddable editor you mount in your own app; it builds and exports the markup but does not send or host it.
-
What does BuilderJS actually give me for RTL email design?
BuilderJS is a framework-agnostic, JSON-first drag-and-drop editor you embed in your own app, with built-in RTL support and i18n covering 20+ locales (locale dictionaries are loaded into the builder via its i18n init, with the editor chrome itself able to render right-to-left), so authors can produce RTL content. Its EmailExportPipeline emits Outlook-safe HTML — flexbox-to-table conversion, SVG-to-PNG rasterizing, `@media` mobile stacking, MSO conditionals, and CSS inlining — the same compatibility work that decides whether your RTL layout survives older clients. You design in the editor, call `getData()` to persist the JSON and `load()` to restore it, and bring your own sending and hosting. It builds the markup; you own the delivery.