What should be mirrored in RTL?

Learn which RTL interface elements should reverse, which must keep their direction, and how to implement and test each decision without flipping content.

Guide15 min read

A global horizontal flip is not RTL support. It reverses Arabic glyphs, logos, photos, charts and values that were already correct. At the other extreme, changing only text alignment leaves back arrows, drawers and ordered controls pointing through an interface that now starts on the right.

The useful question is not whether an object points left or right. Ask what that direction means. If it means inline start, inline end, previous, next, enter from the reading edge or return to the prior screen, it usually follows the interface direction. If it represents physical space, time, media playback, a trademark or the contents of a value, it usually keeps its geometry.

That distinction handles most cases. The rest need a documented product decision, because the same shape can carry different meaning in different components.

The rule: mirror relationships, not pixels#

An RTL interface changes the logical inline axis. Its start edge is on the right and its end edge is on the left. HTML direction gives the browser that information; it is not a request to reflect every painted pixel.

Use three questions for any disputed element:

  1. Is the direction logical? A trailing icon, the next item and a panel entering from inline end should change with reading direction.
  2. Is the direction physical or intrinsic? A map, clock face, product photo, play symbol and phone number keep their own orientation.
  3. Does the asset contain language or culturally interpreted meaning? It may need a localized replacement, not a CSS reflection.

This produces four actions rather than a yes-or-no mirror flag:

MeaningTypical examplesAction
Logical directionBack, forward, previous, next, breadcrumb separatorMirror or select an RTL variant
Logical placementLeading icon, trailing action, navigation rail, drawer edgeReposition with logical CSS
Physical or intrinsic directionPlay, clock, map, graph axis, product photoKeep orientation unless the product convention says otherwise
Language inside an assetScreenshot, annotated diagram, promotional artworkCreate a localized asset

Do not decide from the asset filename alone. An icon named arrow-left says how it was drawn, not what it means. An API named ArrowBack at least expresses intent, but even that can be wrong if the arrow is used to show a physical westward movement.

Start with document direction, not component transforms#

The page should establish Arabic language and direction in markup:

html
<html lang="ar" dir="rtl">

The dir attribute sets the base direction inherited by descendants. lang="ar" alone does not do that. In Chromium 151, an Arabic page without dir still computes to LTR. R001 reports an Arabic page whose root direction is missing or LTR, while R002 reports a missing, non-Arabic or contradictory root language.

Once direction is set, the browser already places the first flex item, grid item and table cell at the right side of an RTL container. It also maps margin-inline-start to the right margin. Let that machinery work before adding RTL overrides.

Problem

css
.breadcrumbs {
  display: flex;
}

[dir="rtl"] .breadcrumbs {
  flex-direction: row-reverse;
}

The RTL override reverses an axis that direction already reversed. In the measured browser, items then appear left to right in DOM order, and Tab moves left to right, so the Arabic trail starts at the far end from where a reader begins. It may look acceptable after someone also rearranges the markup, but visual and keyboard sequences now depend on two competing reversals. R081 reports row-reverse used to imitate RTL instead of document direction.

Better

css
.breadcrumbs {
  display: flex;
  gap: 0.5rem;
}

Keep DOM order meaningful and allow dir to place inline start. Use row-reverse only when the component's actual design calls for the reverse of its current direction, not as a language switch.

Layout should follow start and end#

Navigation rails, form labels, card actions, badges and drawers usually need logical placement rather than mirrored artwork. Replace directional physical properties with CSS logical properties.

Fragile

css
.search-icon {
  left: 0.75rem;
}

.search-input {
  padding-left: 2.5rem;
  text-align: left;
}

Direction-aware

css
.search-icon {
  inset-inline-start: 0.75rem;
}

.search-input {
  padding-inline-start: 2.5rem;
  text-align: start;
}

The icon moves because its relationship to the field start changes. The magnifying-glass drawing itself does not need reflection. This is the difference between mirroring placement and mirroring shape.

The same reasoning applies to margin-inline-end, border-inline-start, inset-inline-end and logical corner properties. R030 reports direction-sensitive physical properties without an RTL override. Physical CSS is not forbidden. Keep left or right when the feature truly refers to a fixed physical side, such as a diagram describing the left side of a machine.

Test layout with Arabic direction on the component's real container, not by dragging it across a design canvas. Inspect computed styles and bounding boxes. Confirm that the component still works when nested inside an opposite-direction region, such as an LTR code example inside the Arabic page.

Back and forward controls describe movement through an interface history. Previous and next move through an ordered collection. Their arrows or chevrons should normally reverse because the interface's reading progression reversed.

Common examples include:

  • a back button in an app header;
  • previous and next pagination controls;
  • carousel navigation tied to logical item order;
  • breadcrumb separators;
  • disclosure chevrons that point toward the edge where content opens;
  • stepper connectors and directional progress indicators.

Mirror the semantic icon, not the entire button. The label remains readable, spacing uses logical properties and the hit area remains unchanged.

css
.icon-next {
  transform: scaleX(1);
}

:dir(rtl) .icon-next {
  transform: scaleX(-1);
}

The :dir() pseudo-class matches an element based on its direction. Prefer it when a component can appear in both LTR and RTL contexts. A root selector such as [dir="rtl"] .icon-next is simpler, but it cannot express a nested LTR region as accurately.

There is one trap: in Chromium 151, CSS direction: rtl changes layout but does not make an element match :dir(rtl). The pseudo-class follows dir attributes. If icon selection depends on :dir(), direction must exist in the document semantics, not only in a stylesheet.

Do not hard-code instructions such as “click the arrow on the left.” The relevant edge changes, and an icon-only label may change with it. Use previous, next, back, expand or collapse. R082 reports UI text that refers to physical arrow directions.

Directional icons need semantic variants#

An icon can be directional even when it is not navigation. Indent and outdent, reply, send, import, export, login, logout and transfer icons often use an arrow whose meaning depends on a boundary or text flow.

These deserve review, not an automatic flip rule:

  • Indent and outdent: Mirror when the icon describes paragraph indentation relative to inline start.
  • Reply and forward: Follow the product's established mail convention and the direction of the message UI. Verify the label because arrow conventions are not self-explanatory.
  • Sign in and sign out: Mirror only if the arrow means movement through the depicted door or boundary and that boundary has been localized.
  • Import and export: Keep the relationship between the arrow and its box. Mirror the complete symbol when the source and destination are logical sides.
  • Sort ascending and descending: Do not mirror a vertical arrow. Its up/down meaning did not change.
  • Undo and redo: Use localized icon variants chosen for the editing convention. Do not assume every curved arrow is tied to reading direction.

The right implementation is usually an icon component with semantic names and direction metadata:

js
const icons = {
  back: { source: "arrow-back.svg", mirrorInRtl: true },
  next: { source: "chevron-next.svg", mirrorInRtl: true },
  play: { source: "play.svg", mirrorInRtl: false },
  download: { source: "download.svg", mirrorInRtl: false },
};

This keeps the decision close to the asset and avoids scattered selectors. It also makes exceptions visible during review. R025 compares an icon's direction with the control it sits in: it reports a "next" arrow that points back toward the start, and flags an unmirrored icon named for a side as worth a look, which is a prompt to inspect its meaning rather than proof that it must flip.

These icons normally stay unchanged#

Symmetric icons and icons with no horizontal meaning do not gain anything from reflection:

  • close, plus, minus, check and warning;
  • search, settings, profile and calendar;
  • download and upload arrows that move vertically;
  • lock, trash, camera and microphone;
  • pause, stop and record;
  • brand marks and product logos.

Some of these look identical after reflection. Still, do not run them through a transform “just in case.” A transformed parent can affect shadows, animation origins, stroke rendering and future asset changes. An icon that is symmetric today may gain a badge or directional detail later.

Brand assets stay as supplied by the owner. Reflecting a wordmark makes it unreadable. If a brand provides an Arabic lockup, choose that asset through locale logic rather than mirroring the Latin version.

The close icon is a useful sanity check. Its action is not “go left” or “go right”; it removes the current surface. Moving the close button from inline end to the opposite physical side may be correct for the component, but the x itself stays unchanged.

Media controls, time and physical space do not follow reading direction#

A play triangle represents playback, not the next word in a sentence. Standard playback controls, scrubber chronology and elapsed-to-remaining time usually keep their established media orientation. Reversing them can make the Arabic version disagree with the same video, audio or editing convention everywhere else in the product.

Keep these physical or intrinsic objects unchanged unless the product domain defines a different convention:

  • play, fast-forward and rewind controls;
  • a video timeline and waveform;
  • analog clock hands and clock faces;
  • maps, compass directions and route geometry;
  • vehicle orientation in a product photo;
  • before-and-after imagery where each side names a real state;
  • scientific, engineering or medical diagrams with physical laterality.

Do not confuse control placement with symbol direction. A media control group may align to the RTL container's start edge while the play symbol and time axis remain unchanged. Likewise, a map's zoom controls can move to avoid an Arabic panel even though the map is not reflected.

Physical laterality can be safety-critical. If a diagram labels left and right sides of a product or body, translate the labels but preserve the depicted object. A localized replacement may be necessary when labels are baked into the image.

Text and values must never be mirrored as graphics#

Arabic text becomes RTL through the Unicode Bidirectional Algorithm and document direction. It is not a bitmap to reverse. Applying transform: scaleX(-1) to a page or content container produces reflected glyphs and makes pointer coordinates, animation and nested transforms much harder to reason about.

Mixed-direction values need isolation, not mirroring:

html
<p dir="rtl">
  الرقم الوظيفي <bdi>7731-04</bdi>
</p>

In Chromium 151, the unisolated employee number after Arabic text displays as 04-7731. That is reordering, not mirroring, and no mirroring rule can fix it: flipping the element would reflect the digits without restoring their order. The value needs isolation. The <bdi> element takes direction from the value and keeps the number together. R021 reports unisolated phones, emails and Latin tokens inside Arabic text.

Phones, emails, URLs, codes and account identifiers often remain LTR inside an RTL interface. Set direction on the value or field when its data model is known:

html
<label for="receipt-email">أرسل الإيصال إلى</label>
<input id="receipt-email" name="receipt-email" type="email" dir="ltr">

Only type="tel" is LTR by default in the measured browser. Email, URL, number, search and text fields inherit the page direction unless they set their own, so this email field needs its dir. R070 reports telephone, email or URL inputs rendered RTL. The field's placement and label can follow RTL while its value remains LTR.

Tables mirror structure, not cell data#

An RTL table normally places its first column at the right edge because the table participates in the page's direction. That is useful when the first column contains the primary row label or action in Arabic reading order.

Cell contents keep their own semantics. Arabic descriptions remain RTL. IDs, email addresses and machine codes may be LTR. Numeric alignment should follow the product's comparison needs, not a global reflection. A column of amounts may use end alignment so decimal structures scan consistently, but the digits are formatted according to the market rule.

Column order is a product decision when users compare the Arabic and English versions side by side or work from a regulated form with fixed field positions. In those cases, preserve the domain's agreed order and localize labels. Do not let a general table component silently reverse a legally meaningful or operational sequence.

Test a dense table with long Arabic headers, sortable columns, row actions, sticky columns and horizontal overflow. Confirm which column is first in DOM order, which edge it occupies and where keyboard focus moves. A correct screenshot is not enough if Tab crosses the row in a sequence that no longer matches its relationships.

Charts and data visualizations need an axis decision#

There is no universal RTL mirroring rule for charts. First decide whether the horizontal axis represents reading order, categories, chronology, magnitude or physical position.

VisualizationDefault review question
Category bar chartShould the first category begin at inline start?
Time seriesIs chronological time required to increase toward a fixed physical side?
Numeric x-axisDoes the domain expect low-to-high to remain left to right?
Process diagramIs the flow tied to reading direction or to a fixed system sequence?
Map or floor planDoes the geometry represent real physical space?

Labels, legends and tooltips should use RTL layout and correct bidi handling even when the plot keeps its orientation. A time-series line can remain physically unchanged while its title, legend and tooltip align to the Arabic interface.

SVG geometry does not automatically mirror when an ancestor becomes RTL. That is usually helpful. If the product decides that a process arrow or categorical axis should reverse, generate an RTL layout or transform the intended graphics group. Do not reflect the root SVG when it contains text, numbers or a logo, because those descendants will reflect too.

Test with asymmetric data. A symmetric chart can hide a reversed scale. Record where the minimum, maximum, first category and latest timestamp are expected, then inspect labels and pointer interaction at both ends.

Photos, illustrations and screenshots need content review#

Most photos and product images should not be mirrored. They show an object, scene or brand as it exists. Reflection can move controls to the wrong side of a photographed device, reverse text on packaging, change handedness or falsify a physical detail.

Illustrations are less predictable. A decorative character looking toward a call to action might need an RTL composition, but flipping the image may reverse clothing details, symbols or embedded text. Ask for a localized crop or source asset when composition matters.

Screenshots almost always need replacement. Reflection leaves every word backward and shows the LTR product. Capture the localized UI at the required viewport instead. The same applies to diagrams with embedded labels: translate the source and re-export it.

Use these review states for image assets:

  • Keep: physical scene, product photo, logo, map or direction-neutral decoration.
  • Recompose: decorative illustration whose visual attention should move toward logical start or end.
  • Recreate: screenshot, annotated diagram or promotional image containing language.
  • Verify with owner: licensed art, trademarked material or a domain diagram where reflection could change meaning.

An image can also contain a directional cue that conflicts with nearby RTL text without needing reflection. Moving the image to the other side of the layout may resolve the composition while preserving the asset.

Motion should follow the edge that owns the component#

Drawers, sheets, menus and toasts often animate from the edge where they are anchored. If a navigation drawer moves from inline start, it should enter from the right in RTL. A transform written as a fixed negative or positive translateX() does not change with dir.

Toasts show it in miniature. One that sits at the inline end and slides in from beyond it has to arrive from the left on an Arabic page:

Problem

css
@keyframes toast-in {
  from { transform: translateX(120%); }
}

.toast {
  position: fixed;
  right: 1rem;
  animation: toast-in 200ms ease-out;
}

One direction-aware approach

css
@keyframes toast-in {
  from { transform: translateX(var(--toast-from)); }
}

.toast {
  position: fixed;
  inset-inline-end: 1rem;
  --toast-from: 120%;
  animation: toast-in 200ms ease-out;
}

.toast:dir(rtl) {
  --toast-from: -120%;
}

R033 reports a translateX that moves an element off-screen in RTL. Verify the resting position, the entry motion and the exit. A toast can arrive from the correct side and still leave across the whole viewport if only one keyframe was localized. Drawers follow the same pattern with a larger offset; the RTL CSS guide works through one.

Not all motion mirrors. A loading spinner, vertical expansion, opacity transition or animation tied to physical drag velocity keeps its behavior. Shadows also need judgment. A shadow used as a directional affordance at a drawer edge may need its horizontal offset reversed. A scene-wide light source should remain consistent. R032 reports direction-sensitive shadow x-offsets and text indentation without an RTL counterpart.

Build one component, with explicit exceptions#

Avoid a separate RTL component tree. Parallel markup drifts, and fixes land in one version first. Prefer shared structure, logical properties and a small set of semantic asset decisions.

An icon wrapper can expose intent instead of physical filenames, and a data attribute keeps the decision in the markup where review sees it:

html
<button class="back-button" type="button">
  <svg class="icon" data-mirror="rtl" aria-hidden="true"><!-- path --></svg>
  <span>العودة</span>
</button>
css
[data-mirror="rtl"]:dir(rtl) {
  transform: scaleX(-1);
}

If the icon already uses transform for animation, do not overwrite it with another transform declaration. Wrap the SVG, combine transform functions or select a separate asset. Test focus, hover, pressed and disabled states because state styles frequently replace transforms.

Keep direction at the narrowest semantic boundary. A code editor, phone value or embedded English quote may be LTR inside an Arabic page. Conversely, an Arabic preview can be RTL inside an English administration screen. Component logic should respond to its own computed context, not assume that the application locale tells the whole story.

Test meaning, geometry and interaction separately#

Review each disputed component in LTR and RTL using asymmetric content. Run the RTL case with Arabic labels long enough to wrap. Then inspect three layers:

Meaning#

State what the direction represents. For a chevron, is it previous, physical left, collapsed, or the edge where a panel will open? If the team cannot name the meaning, the implementation will become a collection of one-off flips.

Geometry#

Inspect computed direction, logical insets, transforms and bounding boxes. Check narrow, intermediate and wide viewports. Open overlays and load late content. Watch both horizontal edges for overflow.

Interaction#

Use the keyboard, pointer and touch behavior the component supports. Confirm that visual order, DOM order, focus order and arrow-key behavior describe the same task. Test animation from start to finish rather than pausing only at the open state.

A useful test record says more than “icon mirrored.” It states the semantic role, expected edge, expected orientation, actual result, route, viewport and state. For example: “Checkout header, back action, RTL, arrow points toward inline start, focus returns to the prior control after navigation.”

A release matrix for mirroring decisions#

Do not leave decisions in comments scattered across CSS. Record them in the component specification or localization notes so design, engineering and QA test the same behavior.

ElementPlacement in RTLShape in RTLTest
Back or next buttonFollow component layoutMirror directional arrowNavigate both ways and check focus
Breadcrumb separatorBetween items in RTL orderMirror chevronTest long and wrapped crumbs
Search field iconMove with logical start or endKeep magnifierType Arabic and LTR queries
Navigation drawerAnchor to defined logical edgeKeep non-directional iconsTest entry, exit and overlay focus
Close buttonUsually move with component edgeKeep xOpen and close by keyboard
Phone or emailPosition inside RTL formKeep value LTRType, paste, select and copy
Media controlsFit RTL surrounding layoutKeep playback symbols and time axisPlay, seek, rewind and inspect labels
Data tablePut first logical column at start unless domain fixes orderPreserve cell semanticsCheck DOM, visual and focus order
ChartLocalize surrounding UIFollow documented axis contractUse asymmetric endpoints
Product photo or mapReposition if composition requiresKeep physical geometryCheck embedded text and laterality
Screenshot or labeled diagramPlace in RTL compositionReplace with localized assetRead every embedded label

Treat an unresolved high-impact item as a release question, not a visual polish task. A wrong back arrow can send users toward the opposite action. A reflected medical diagram can change meaning. A mirrored phone value can corrupt what the user reads. The decision is ready only when its meaning, implementation and verification agree.

Ritla can surface the structural failures around this review: R025 for an arrow that points against its control, R030 for direction-sensitive physical properties without an RTL override, R033 for transforms that push an element off-screen, and R081 for row-reverse used to fake RTL. Run a free scan, then judge the meaning of each flagged element in its product context; the scan can find the arrow, but only the team can say what it means.

For the CSS behind each decision, see the RTL CSS guide. For where direction itself comes from, see the complete guide to dir="rtl".

Checks in this guide

Show every check in this guideShow fewer

See what your Arabic pages are hiding

Paste a URL. Ritla renders the page on desktop and mobile, runs every check, and shows the top issues with screenshot evidence.