RTL Website Design: A Practical Guide

A website built for a left-to-right language and then "flipped" for Persian or Arabic almost always feels subtly wrong, even to visitors who cannot name why. Icons point the wrong way, a progress bar fills backward, a form field aligns oddly, or numbers read in the wrong order next to Persian text. None of these individually breaks the site, but together they signal, quietly and immediately, that the right-to-left version was an afterthought rather than a real design decision. This guide covers what genuinely needs attention, based on building bilingual Persian and English sites.

Mirroring is structural, not cosmetic

The starting point is the dir="rtl" attribute on the page's root element, combined with lang set to the correct language code. This single attribute does more work than it gets credit for: it flips the default text direction, the default alignment of block elements and the logical reading order of the layout. CSS logical properties, margin-inline-start instead of margin-left, padding-inline-end instead of padding-right, follow this direction automatically, which is why building with logical properties from the start saves a great deal of rework compared to retrofitting a left-to-right design later.

Not everything should mirror, and getting this distinction wrong is one of the most common RTL mistakes. Navigation, text alignment, form layout and most icons that imply direction, such as arrows and chevrons, should mirror. A play button, a clock icon, a company logo, a video progress bar and most brand elements should not mirror, because they do not carry directional meaning the way an arrow does. A rule of thumb: if the icon means "forward" or "back," it should flip; if it represents a physical object or a fixed logo, it should not.

Typography for Persian and Arabic

Latin web fonts are not interchangeable with Persian and Arabic typefaces, and using one font for both without checking the result is a common source of oddly spaced, hard-to-read Persian text. A typeface designed for Persian, such as Vazirmatn or IRANSans, renders the script's joined letterforms and diacritics correctly and at a readable weight. Line height usually needs to be slightly larger for Persian script than for Latin text at the same point size, because Persian letterforms have more vertical variation. Letter-spacing adjustments, common in Latin typography for headlines, should generally be avoided in Persian, since artificial spacing between joined letters breaks the script's natural connections.

Numbers and mixed-direction content

This is where many otherwise careful RTL implementations go wrong. Arabic-indic or Persian digits are written left-to-right even inside right-to-left text, the same way a phone number or a date embedded in an English sentence does not reverse. A price, a phone number, or a date mixed into a Persian sentence needs to render in the correct internal direction while sitting correctly within the surrounding right-to-left flow. The Unicode bidirectional algorithm handles most of this automatically in modern browsers, but it can be broken by careless use of direction or manual unicode-bidi overrides, so test real mixed content, not just pure Persian or pure English strings, before trusting a layout.

Forms, dates and inputs

Form fields should align to match the reading direction, with labels positioned correctly relative to their inputs. Placeholder text and input alignment should follow the field's content language, which matters specifically when a form mixes a Persian label with an English email field or a Latin-alphabet phone number. Date pickers deserve particular attention: if your business or audience uses the Jalali (Persian) calendar alongside or instead of the Gregorian calendar, decide early which one the interface uses by default, and be explicit about which one is stored and displayed, because mixing the two silently is a frequent source of real scheduling errors, not just a cosmetic one.

Testing an RTL site properly

Do not trust a design file. Test the built pages, because interactions between frameworks, and third-party components frequently break mirroring in ways that are invisible in a static mockup. Check navigation menus, dropdown direction, modal and tooltip positioning, carousel and slider direction, and any component borrowed from a library that was not built with RTL in mind, since many popular UI libraries default to left-to-right behavior even when the page direction is set correctly. Check the browser's own zoom and text-scaling, since RTL layouts can break in subtle ways under 200 percent zoom that a left-to-right layout would not.

Why this matters for SEO and trust

A site that gets RTL wrong does not just look unpolished, it signals a lower-quality, lower-trust experience to a Persian or Arabic-speaking visitor the same way a sloppy translation would, and that impression affects conversion even when every individual bug is minor. From an SEO standpoint, correct lang and dir attributes also matter for accessibility tools and, alongside correct hreflang annotations, for how search engines understand and serve language-specific versions of your pages, which we cover in our guide to SEO for bilingual websites.

Common frameworks and libraries: what to check

Most CSS frameworks now ship RTL support, but "supports RTL" varies enormously in practice, from genuinely logical-property-based styles to a bolted-on stylesheet that only handles the common cases. Before committing to a component library for a bilingual project, build one real page with mixed Persian and English content, including a form, a dropdown and an icon, and check it in both directions rather than trusting the library's documentation claims. Icon sets are a frequent gap: a popular icon library may mirror arrows automatically when the page direction changes, or it may not, and this is worth testing explicitly rather than assuming.

RTL is not only Persian and Arabic

Hebrew and Urdu also read right-to-left and share many of the same technical considerations, though their typography and digit conventions differ from Persian's in ways that deserve their own review rather than reusing Persian settings wholesale. If a project needs to support more than one right-to-left language, treat each one as its own typography and testing pass rather than assuming RTL support is a single uniform setting.

A short checklist

1. Set dir="rtl" and the correct lang on the page root, not just on a wrapping div.
2. Use CSS logical properties instead of physical left and right properties throughout.
3. Mirror directional icons; do not mirror logos, fixed objects or non-directional icons.
4. Use a typeface actually designed for Persian or Arabic, with adjusted line height.
5. Keep embedded numbers, dates and Latin text in their correct internal direction.
6. Decide explicitly on Jalali versus Gregorian dates and be consistent about which is stored.
7. Test every interactive component in the browser, not only the static design.
8. Check third-party embeds (maps, payment widgets, video players) for direction issues separately, since they are outside your own CSS control.

Building RTL correctly from the start is far cheaper than retrofitting it, which is one of the advantages of a framework like Next.js when it is set up with logical CSS and proper locale routing from the first commit, something we cover in our article on why Next.js suits bilingual business websites. None of this is exotic engineering, but it is easy to skip under deadline pressure, which is exactly when it tends to get skipped. If you want your own site reviewed for these details, our web design and development service includes bilingual Persian-English and RTL work as a core specialty, not an add-on.