Five Mistakes That Break Arabic Websites — And Why They Keep Happening in Almost Every Project

RTL issues are not cosmetic details. They are usually the result of designing and developing the interface for English first, then trying to adapt it to Arabic later.

The difference between a website that supports Arabic and one that is actually designed for Arabic appears in the small details that Saudi users notice immediately — but developers testing primarily in English often miss.

Here are five common mistakes that appear in almost every Arabic web project, why they happen, and how to avoid them from the beginning.

1. Using left and right Instead of Logical Properties

This is one of the most common RTL mistakes.

When you write a layout using fixed directional properties such as margin-left or padding-right, you are hard-coding the direction into the interface. When the page switches to RTL, those values do not automatically adapt.

The better approach is to use CSS logical properties such as:

• margin-inline-start
• margin-inline-end
• padding-inline-start
• padding-inline-end
• border-inline-start
• border-inline-end

The same principle applies to text alignment.

Instead of thinking in terms of:

left vs. right

think in terms of:

start vs. end

This allows the same component to work naturally in both LTR and RTL layouts without creating a separate set of directional fixes.

Modern browsers provide excellent support for logical CSS properties, so there is little reason to keep building new interfaces around hard-coded left and right positioning.

2. Placing dir="rtl" on an Inner Element Instead of the Document

RTL is inherited.

That means the direction should normally be established at the document level rather than being added randomly to individual sections of the page.

A common mistake is to add RTL to a container somewhere in the middle of the page. The result can be a partially RTL interface where some components behave correctly while others continue behaving as LTR.

The correct foundation is to define the document language and direction properly.

For an Arabic page, this means using:

lang="ar"

together with:

dir="rtl"

at the document level.

The language attribute is important as well. It helps accessibility tools and screen readers understand that the content is Arabic and should be pronounced accordingly.

RTL should be treated as a fundamental property of the document, not as a styling patch applied to individual components.

3. Icons That Should Not Be Mirrored

Automatic mirroring can create another class of RTL problems.

Not every icon should be flipped when the interface changes direction.

Directional icons are usually expected to change.

For example, a Next arrow should point toward the correct direction of movement in an RTL interface.

But many other icons should remain exactly as they are.

Examples include:

• Play icons
• Brand logos
• Social media icons
• Location symbols
• Product icons
• Universal status icons

Consider the familiar play button:

▶

If you automatically mirror it, it can become visually confusing because the icon no longer communicates the same universal meaning.

The general rule is simple:

Mirror icons that communicate direction. Keep icons that communicate a fixed concept unchanged.

This distinction becomes particularly important in navigation systems, dashboards, mobile interfaces, and complex web applications.

4. Numbers, Dates, and Mixed-Direction Content

Arabic is read from right to left, while numbers generally follow a left-to-right sequence.

This creates a subtle problem when Arabic text and numbers appear together.

Phone numbers are a common example.

A sentence such as:

Call us at +966 54 291 7263 anytime.

contains Arabic text, Latin characters, a plus sign, spaces, and numbers.

Without properly isolating the different directional content, browsers can sometimes display the sequence differently from what the developer intended, particularly when the content contains symbols, parentheses, international phone prefixes, or mixed scripts.

The same issue can appear with:

• Phone numbers
• Prices
• Dates
• Invoice numbers
• Product codes
• Tracking numbers
• URLs
• Email addresses
• Serial numbers

The solution is to treat mixed-direction content deliberately instead of assuming that RTL will automatically solve everything.

Arabic interfaces are not simply mirrored English interfaces.

They contain multiple writing directions that need to coexist correctly.

5. Fonts That Do Not Properly Support Arabic

Choosing a font for an Arabic website is not simply a visual decision.

A Latin font that looks excellent in English may perform poorly when used with Arabic.

The most problematic cases are often fonts that appear to support Arabic at first glance, but have issues with:

• Letter connections
• Arabic shaping
• Diacritics
• Hamza variations
• Lam-alif combinations
• Different Arabic character forms
• Line height
• Vertical alignment

A proper Arabic font should be tested with real Arabic content rather than a single word such as "Hello" or "مرحبا".

Test it with content containing different Arabic letter combinations, diacritics, names, numbers, and long paragraphs.

For example, test words containing:

مُبَرمِج

rather than relying only on basic Arabic text.

There is also a performance consideration.

Loading multiple weights of an Arabic font can add significant page weight. If your website only uses three font weights, there is little reason to load six or seven.

Use only the weights your design actually needs.

Arabic Should Be Designed From the Beginning

All of these problems can be fixed.

But fixing them after a website has already been built can be considerably more expensive than designing the system correctly from the beginning.

Every component may need to be reviewed:

• Navigation
• Cards
• Buttons
• Forms
• Tables
• Icons
• Spacing
• Typography
• Numbers
• Animations
• Responsive layouts

And every new component can potentially introduce another RTL issue.

This is why Arabic support should not be treated as a translation task.

It is an architectural decision.

Arabic-First Development

The right question is not:

"Does this website support Arabic?"

The better question is:

"Was this website designed to work naturally in Arabic?"

That distinction matters.

A website can technically display Arabic while still having poor spacing, incorrect icon directions, broken number formatting, unsuitable typography, and layouts that feel like a reversed English interface.

A truly Arabic-first website starts with RTL as part of its foundation.

This is also the approach behind Moparmeg, a Saudi platform for building websites with AI from Arabic descriptions, with native RTL support rather than treating Arabic as an afterthought. You describe what you want in Arabic and generate a website using modern technologies such as Tailwind CSS without having to manually repair the direction after every generation.

Whether you use an AI website builder or develop everything manually, the principle remains the same:

Arabic is not a translation added at the end. It is an architectural decision made at the beginning.

Final Takeaway

Building a high-quality Arabic website requires more than translating English content and changing the text direction.

RTL affects the entire interface:

Layout. Typography. Icons. Numbers. Navigation. Components. Accessibility. Performance.

The best Arabic experiences are created when these considerations are part of the design and development process from day one.

Build Arabic-first.

Not English-first with an RTL patch.