Tailwind Logical Properties & RTL Support: Bidirectional Layouts Without Hacks

1. The RTL problem with physical CSS classes

A common scenario: a shop system is being localized for the Arabic market. The base structure is in place, the translations are finished, but the layout has to be mirrored. Navigation icons that sit on the left should sit on the right. Padding-left should become padding-right. Corners that are rounded on the left should be rounded on the right. The classic solution: a separate RTL stylesheet that overrides all physical CSS classes. With Tailwind CSS and physical classes such as ml-4, pl-6, rounded-l-lg, that means writing an RTL override version for every single one of these classes.

The problem is not just the effort but the maintainability: if a spacing class changes in the LTR version, the change has to be mirrored in the RTL version in sync. On teams that do not work with RTL layouts every day, that often does not happen. The result is subtle layout bugs in RTL mode that only surface once native speakers test the page. Tailwind Logical Properties remove this problem structurally: a single class works correctly in both writing directions, because it defines direction as a conceptual property (start/end) rather than a physical one (left/right).

2. CSS Logical Properties: the concept explained

CSS Logical Properties are a W3C standard that replaces physical CSS properties such as margin-left and padding-right with writing-direction-relative equivalents. The core concept: instead of "left" and "right" there is "start" (inline-start) and "end" (inline-end). In LTR languages (English, German, French), "start" is left and "end" is right. In RTL languages (Arabic, Hebrew, Persian), "start" is right and "end" is left. The vertical axis has the corresponding concepts of "block-start" (top) and "block-end" (bottom).

The Tailwind Logical Properties implementation translates these concepts into a consistent class-naming convention: the prefix m stands for margin, p for padding, s for start (inline-start), and e for end (inline-end). So: ms-4 is margin-inline-start: 1rem, and pe-6 is padding-inline-end: 1.5rem. This short notation is consistent with Tailwind's existing class-naming philosophy and requires very little getting used to for developers already familiar with ml, mr, pl, pr.

/* CSS Logical Properties: what Tailwind generates */

/* Physical (old), breaks in RTL */
.ml-4 { margin-left: 1rem; }      /* Always left, even in RTL */
.pl-6 { padding-left: 1.5rem; }   /* Always left */

/* Logical (new), adapts to writing direction */
.ms-4 { margin-inline-start: 1rem; }   /* Left in LTR, right in RTL */
.me-4 { margin-inline-end: 1rem; }     /* Right in LTR, left in RTL */
.ps-6 { padding-inline-start: 1.5rem; } /* Left in LTR, right in RTL */
.pe-6 { padding-inline-end: 1.5rem; }   /* Right in LTR, left in RTL */

/* Block axis: top/bottom (independent of writing direction) */
/* These are already logical: mt, mb, pt, pb = block-start/end */

/* Logical equivalents for other properties */
.start-0 { inset-inline-start: 0; }    /* left:0 in LTR, right:0 in RTL */
.end-0   { inset-inline-end: 0; }      /* right:0 in LTR, left:0 in RTL */

/* Rounded corners, logical */
.rounded-s-lg { border-start-start-radius: 0.5rem; border-end-start-radius: 0.5rem; }
.rounded-e-lg { border-start-end-radius: 0.5rem; border-end-end-radius: 0.5rem; }

/* Border, logical */
.border-s { border-inline-start-width: 1px; }
.border-e { border-inline-end-width: 1px; }

3. Tailwind logical-properties classes: ms, me, ps, pe

Tailwind CSS introduced full support for Logical Properties in v3.3. The classes ms-*, me-*, ps-*, pe-* replace ml-*, mr-*, pl-*, pr-* for writing-direction-dependent layouts. All Tailwind spacing values are available: ms-0 through ms-96, arbitrary values with ms-[20px], negative values with -ms-4, and responsive variants with sm:ms-8. The JIT engine generates the corresponding margin-inline-start and padding-inline-start CSS rules.

In practice, this is what Tailwind RTL support means: you write the layout once with logical classes, and it works correctly in both writing directions. A button with an icon to the left of the text: class="flex items-center gap-2 ps-3 pe-4". In LTR mode, the button has more padding on the right (pe-4) and less on the left (ps-3), where the icon sits. In RTL mode this flips automatically: the icon is on the right, the larger padding is on the left. No overrides, no separate RTL classes, no JavaScript direction detection needed.

4. Logical borders, rounded corners, and inset

Besides spacing, Tailwind Logical Properties also cover border widths, border radii, and positioning. The classes border-s and border-e set the border on the start or end side of an element. rounded-s-* and rounded-e-* round the start or end side of the element. This is especially relevant for tab navigation, where the active tab often has a border on the left side (LTR); with border-s-4, this border automatically moves to the right side in RTL mode.

The positioning classes start-* and end-* replace left-* and right-* for absolutely and fixed positioned elements. A dropdown aligned to the left edge of its parent via left-0 should sit on the right edge in RTL mode. With start-0, that happens automatically. For float properties there are float-start and float-end as logical equivalents of float-left and float-right. In projects with body text and embedded images, these logical float classes are especially valuable.

<!-- RTL-compatible navigation with Tailwind Logical Properties -->
<nav dir="ltr" class="flex items-center gap-4 px-4 py-3 bg-white border-b border-slate-200">
  <!-- Logo: always at inline-start (left in LTR, right in RTL) -->
  <a href="/" class="flex items-center gap-2 me-auto">
    <img src="/logo.svg" alt="Logo" class="h-8 w-auto">
    <span class="font-bold text-slate-900">Mironsoft</span>
  </a>

  <!-- Nav links -->
  <div class="flex items-center gap-1">
    <!-- Active state: border at inline-start side -->
    <a href="/blog" class="flex items-center gap-1.5 px-3 py-2 rounded-lg text-sm font-medium
                           border-s-2 border-sky-600 text-sky-700 bg-sky-50 ps-2.5">
      Blog
    </a>
    <a href="/contact" class="flex items-center gap-1.5 px-3 py-2 rounded-lg text-sm
                              font-medium text-slate-600 hover:bg-slate-100">
      Contact
    </a>
  </div>

  <!-- Search icon: at inline-end -->
  <button class="p-2 rounded-lg hover:bg-slate-100 ms-2" aria-label="Search">
    <svg class="w-5 h-5" fill="none" stroke="currentColor" viewBox="0 0 24 24">
      <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2"
            d="M21 21l-6-6m2-5a7 7 0 11-14 0 7 7 0 0114 0z"/>
    </svg>
  </button>
</nav>

<!-- RTL version: just change dir="ltr" to dir="rtl", layout flips automatically -->
<!-- No additional CSS or class changes needed -->

5. The dir attribute and writing-direction variants

The HTML dir attribute is the standard mechanism for controlling the writing direction of a page or element. dir="ltr" sets LTR (left-to-right), dir="rtl" sets RTL (right-to-left). Tailwind CSS uses this attribute for its writing-direction variants: with the rtl: and ltr: prefixes you can define classes that are only active in the corresponding writing direction. These variants are the bridge for cases where logical properties alone are not enough, such as icons that need to be mirrored, or animations that slide in from one side.

In practice, for Tailwind RTL support, the dir attribute is often set dynamically via JavaScript when the user switches language. On server-rendered pages such as Magento, dir is typically set on the <html> tag based on the active locale. Tailwind's rtl: variant reacts to any dir="rtl" attribute anywhere in the DOM tree, including on a parent element, not just on the <html> tag. That makes it possible to apply RTL layouts to individual sections of a page while the rest stays LTR.

<!-- dir-variant examples: rtl: and ltr: prefixes -->

<!-- Arrow icon: flip horizontally in RTL -->
<button class="flex items-center gap-2 px-4 py-2 rounded-lg bg-sky-600 text-white">
  <span>Next</span>
  <!-- Chevron right in LTR, flip to point left-facing arrow in RTL -->
  <svg class="w-4 h-4 rtl:rotate-180 transition-transform" fill="none"
       stroke="currentColor" viewBox="0 0 24 24">
    <path stroke-linecap="round" stroke-linejoin="round" stroke-width="2"
          d="M9 5l7 7-7 7"/>
  </svg>
</button>

<!-- Sidebar: slides in from left (LTR) or right (RTL) -->
<aside class="fixed inset-y-0 start-0 w-64 bg-white shadow-xl
              transform -translate-x-full rtl:translate-x-full
              transition-transform duration-300"
       id="sidebar">
  <!-- Sidebar content -->
</aside>

<!-- Gradient: flows from start (left/right depending on dir) -->
<div class="bg-gradient-to-r ltr:from-sky-600 ltr:to-transparent
                              rtl:from-transparent rtl:to-sky-600 h-1">
</div>

<!-- Text alignment: always toward inline-start regardless of direction -->
<!-- Use text-start / text-end instead of text-left / text-right -->
<p class="text-start">Left-aligned in LTR, right-aligned in RTL</p>
<p class="text-end">Right-aligned in LTR, left-aligned in RTL</p>

6. Text alignment and float in RTL layouts

Text alignment is one of the most common pitfalls in Tailwind RTL layouts. The physical classes text-left and text-right set text-align: left and text-align: right regardless of writing direction. In RTL text, "left-aligned" is often the wrong choice: Arabic text should by default be right-aligned, because that matches its natural reading direction. The logical equivalents text-start and text-end set text-align: start and text-align: end, which orient themselves to the writing direction.

Floated elements, such as images in body-text articles, also benefit from Tailwind Logical Properties. Instead of float-left for an image that text should wrap around, you write float-start. In LTR mode, the image floats left and text flows around it on the right. In RTL mode, the image floats right and text flows around it on the left. That is the natural behavior for bidirectional content pages. The same applies to clear-start and clear-end as logical equivalents of clear-left and clear-right.

7. Migrating from physical to logical classes

Migrating an existing Tailwind project to Logical Properties for RTL support can be done systematically. The first step: identify all physical direction classes. These are ml-*, mr-*, pl-*, pr-*, left-*, right-*, rounded-l-*, rounded-r-*, border-l, border-r, text-left, text-right, float-left, and float-right. A regular expression across all template files finds every occurrence.

The second step is the distinction: not every physical class needs to be replaced. ml-auto to push an element left within a flexbox makes sense, since you explicitly want the element on the left. Only when a class should describe writing-direction-dependent behavior does the logical variant come into play. That is a conceptual decision: "Should this element always be on the left (physical), or always at the start of the writing direction (logical)?" Making that distinction is the actual work of the migration; the technical swap itself is done quickly with search and replace.

8. Physical vs. logical Tailwind classes: a direct comparison

An overview of the correspondences between physical and logical Tailwind Logical Properties classes shows how consistent the system is.

The table shows: for every horizontal physical property there is a logical equivalent with s (start) or e (end). Vertical properties such as mt, mb, pt, pb are already writing-direction-independent, because vertical direction is the same across all common languages. The Tailwind Logical Properties migration is therefore manageable for most projects: you only replace horizontal direction classes, everything else stays unchanged.

9. Browser support and fallback strategies

CSS Logical Properties are fully supported by all modern browsers: Chrome from version 69, Firefox from version 41, Safari from version 12.1, and Edge from version 79. That makes Tailwind Logical Properties practical for every current project without polyfills or fallbacks. The only relevant exception is Internet Explorer 11, which does not support CSS Logical Properties, but its market share in 2026 is below 0.5% and it is no longer supported by Tailwind CSS itself.

For projects that need older browser support for historical reasons, there are two strategies: either use Tailwind's rtl: variant together with physical classes (more code, but full control), or use a PostCSS plugin such as postcss-logical, which compiles Tailwind Logical Properties automatically into physical fallbacks. The latter lets you use logical Tailwind classes in the source code, while the output CSS contains physical properties that older browsers understand too.

/* postcss.config.js: add postcss-logical for older browser support */
module.exports = {
  plugins: [
    require('tailwindcss'),
    /* Compile logical properties to physical for IE11 compatibility */
    require('postcss-logical')({
      /* Direction: needed for accurate compilation of start/end */
      dir: 'ltr', /* Compile for LTR, RTL fallback via separate stylesheet */
    }),
    require('autoprefixer'),
  ],
}

/* Result: ms-4 compiles to both: */
/* margin-inline-start: 1rem; (for modern browsers) */
/* margin-left: 1rem;         (for IE11 fallback) */

/* Tailwind config: enable rtl/ltr variants if needed alongside logical */
module.exports = {
  /* ... */
  /* In Tailwind v3, rtl/ltr variants are enabled by default */
  /* Usage: rtl:ml-0 rtl:mr-4 for explicit physical overrides in RTL context */
}

10. Summary

Tailwind Logical Properties, meaning ms, me, ps, pe, start, end, rounded-s, rounded-e, border-s, border-e, text-start, text-end, float-start, float-end, enable bidirectional layouts without a separate RTL stylesheet. A layout that is written once with logical classes works correctly in both LTR and RTL, since the writing direction of the parent element is controlled through the dir attribute. That eliminates the maintenance overhead of separate RTL overrides and ensures layout changes automatically apply in both directions.

For migration: identify horizontal physical classes, conceptually decide whether physical or logical behavior is wanted, and use the corresponding logical class. For cases that logical properties do not cover, the rtl: and ltr: variants are available. Browser support is complete across all modern browsers. Anyone starting a new Tailwind project today with a potential RTL requirement should use Tailwind Logical Properties from the start. The extra effort compared to physical classes is minimal, and later RTL support comes along for free.