Arabic and RTL Web App Development: A Practical Guide
For companies selling to the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain, or Oman, an English-only application is often not enough. Customers, employees, and government partners increasingly expect software that works naturally in Arabic, and some documents are required to be in Arabic by regulation. Arabic is written from right to left, which affects much more than the direction of the text: navigation, icons, forms, tables, and even the order of steps in a checkout flow all change. Many applications that add Arabic late end up with broken layouts, mirrored logos, and numbers in the wrong place. This guide explains how to build Arabic and right-to-left (RTL) support properly from the start, with practical guidance for Next.js and Laravel projects.
Why Arabic Support Matters in the Gulf
Across the Gulf, business software is commonly bilingual. English is widely used in commerce, but Arabic remains the official language, and many users, especially in government, public sector, and traditional industries, prefer to work in it. Offering a polished Arabic experience signals that a product is built for the region rather than adapted as an afterthought.
There are also concrete requirements. In Saudi Arabia, VAT regulations require tax invoices to be issued in Arabic, although other languages may appear alongside it. Any system that generates invoices, quotes, or official documents for Saudi customers therefore needs reliable Arabic output, including in PDFs and e-invoicing data. Government and enterprise tenders in the region also frequently list Arabic support as a requirement.
RTL Is More Than Translation
Switching a page to right-to-left starts with two attributes on the root element: lang="ar" and dir="rtl". The browser then reverses the inline direction, so text aligns to the right, flex and grid rows flow from right to left, and table columns start on the right. This is the foundation, but it only works well if the rest of the interface was built to respond to direction instead of hard-coding left and right.
In practice, an RTL interface is a mirror image of the LTR version. The navigation menu moves to the right, the back button points to the right, progress bars fill from right to left, and side panels open from the opposite side. Users notice immediately when this is inconsistent, and a half-mirrored interface feels broken even if every word is translated correctly.
Build Layouts with CSS Logical Properties
The most important technical decision is to stop using physical directions in CSS. Properties like margin-left, padding-right, and text-align: left assume a left-to-right page. Their logical equivalents, margin-inline-start, padding-inline-end, and text-align: start, automatically follow the direction of the document. A layout built with logical properties works in both English and Arabic without a separate stylesheet.
Modern CSS frameworks support this approach. Tailwind CSS, for example, offers logical utilities such as ms-4 and pe-2 for margins and padding, and rtl: and ltr: variants for the rare cases where a direction-specific style is needed. Flexbox and CSS Grid already respect the document direction, so most layouts mirror correctly once physical properties are removed.
What to Mirror and What to Leave Alone
Not everything should flip. A useful rule is that anything representing direction or sequence mirrors, while anything representing a real-world object or a fixed standard does not.
- Mirror: navigation arrows, back and forward buttons, breadcrumbs, progress indicators, sliders, carousels, step-by-step flows, and the position of sidebars and drawers.
- Do not mirror: logos, product photos, media play buttons, clocks, checkmarks, and icons that depict real objects.
- Keep left-to-right: phone numbers, email addresses, URLs, IBANs, code snippets, and product codes, even inside Arabic text.
- Decide deliberately: charts and timelines. Some teams mirror time axes for Arabic users, others keep them left to right; the important thing is to choose consistently.
Handling Mixed Arabic and English Text
Real content is rarely purely Arabic. Product names, brand names, numbers, and email addresses often appear in the middle of Arabic sentences, and user-generated content can be in either language. The Unicode bidirectional algorithm handles most of this automatically, but punctuation and numbers at the boundaries of mixed text can end up in surprising positions.
Two techniques solve most problems. Wrap user-supplied or unknown-direction text in the <bdi> element or give it dir="auto", so the browser determines its direction from its content. Set dir="ltr" explicitly on fields and values that must always read left to right, such as email, phone, and reference number inputs. These small details prevent many of the bugs Arabic users report.
Typography for Arabic
Arabic script is connected and has taller ascenders and descenders than Latin script, so fonts designed only for English often render Arabic poorly or fall back to a system font that clashes with the design. Choose a typeface with a well-designed Arabic version, such as Noto Sans Arabic, IBM Plex Sans Arabic, Cairo, or Tajawal, and pair it with a matching Latin font.
A few typographic rules are specific to Arabic. Increase line height slightly, because Arabic glyphs need more vertical space. Never apply letter spacing to Arabic text, as it breaks the connections between letters. Text transformations such as uppercase have no meaning in Arabic. Finally, expect text length to change: Arabic translations can be shorter or longer than English, so buttons and labels must not depend on fixed widths.
Numbers, Dates, and Currency
Arabic interfaces can display numbers using Western digits (0123) or Eastern Arabic digits (٠١٢٣). Usage differs between countries and contexts, and many Gulf businesses use Western digits in software. Rather than hard-coding a choice, use the browser's Intl APIs with the appropriate locale, such as ar-AE or ar-SA, and set the numbering system explicitly when you need consistency.
Dates deserve the same care. In Saudi Arabia, the Hijri calendar is widely used alongside the Gregorian calendar, and some official contexts require Hijri dates. Intl.DateTimeFormat supports the Umm al-Qura calendar through the islamic-umalqura calendar option. Currency formatting for AED, SAR, and other Gulf currencies should also come from locale-aware formatting, not manual string building.
Forms, Search, and Data Entry
Forms are where RTL problems are most visible. Labels, validation messages, and helper text must align correctly, input icons must move to the opposite side, and date pickers must open in the right direction. Fields for email, phone numbers, and URLs should stay left to right even in an Arabic form, while names and addresses should follow the user's input.
Search needs extra attention. Arabic has several forms of some letters, such as different variants of alef, and optional diacritics that users rarely type. Without normalization, a search for a product name may miss results that differ only in these details. Normalizing text before indexing and searching gives Arabic users the results they expect.
Implementing Arabic and RTL in Next.js
In a Next.js App Router project, the cleanest approach is locale-based routing, with paths such as /en and /ar. The root layout reads the locale and sets lang and dir on the <html> element on the server, so the page arrives already in the correct direction without a flash of mirrored content. Libraries such as next-intl handle routing, message files, and locale-aware formatting.
Server-side rendering is a real advantage here. Because the HTML is generated with the correct direction and language, search engines index each version properly, and users on slower connections never see a layout jump from left to right. Metadata, including translated titles, descriptions, and hreflang alternates, can be generated per locale with the Metadata API.
Implementing Arabic and RTL in Laravel
Laravel has built-in localization through language files in the lang directory, and a small middleware can set the application locale from the URL, a user preference, or a header. Blade layouts can then output the correct lang and dir attributes, and Carbon can format dates in Arabic. For content stored in the database, packages such as spatie/laravel-translatable make it straightforward to keep Arabic and English versions of the same record.
Generated documents are a common pitfall. Arabic letters change shape depending on their position in a word, and some PDF libraries do not handle this shaping or right-to-left text correctly, producing disconnected or reversed letters. When invoices or reports must be produced in Arabic, choose a PDF solution with proven Arabic support and test real documents early, rather than discovering the problem when a Saudi customer receives an unreadable invoice.
Arabic SEO
If the Arabic version of your site should rank in search engines, give it its own URLs, translated titles and meta descriptions, and hreflang tags that connect each Arabic page to its English equivalent. Decide whether slugs will be in Arabic script or transliterated Latin characters and apply the choice consistently. Above all, use real translation and local keyword research: the terms people search for in Arabic are not always direct translations of English keywords.
Testing an RTL Application
RTL issues are easy to miss for teams that do not read Arabic. Test every screen in both directions, including emails, PDFs, error pages, and empty states. Visual regression tests that capture both versions catch layout changes early. Most importantly, involve a native Arabic speaker in review: they will spot unnatural translations, awkward line breaks, and cultural details that automated tests never find.
Frequently Asked Questions
What does RTL mean in web development?
RTL stands for right-to-left. It describes languages such as Arabic, Hebrew, Persian, and Urdu, which are read from right to left. An RTL web interface mirrors the usual layout so that text, navigation, and the flow of the page start on the right side.
Can an existing English application be converted to support Arabic?
Yes. The work usually involves replacing physical CSS properties with logical ones, extracting all text into translation files, adding locale-aware formatting for numbers and dates, and fixing components that assume left-to-right layout. The effort depends on how the original interface was built, which is why adding RTL support early is much cheaper than adding it later.
Should Arabic interfaces use Western or Eastern Arabic numerals?
Both are used. Many business applications in the Gulf use Western digits, while some contexts and audiences prefer Eastern Arabic digits. The best approach is to use locale-aware formatting, decide on a consistent numbering system for your audience, and keep critical values such as phone numbers and reference codes in a predictable format.
Do invoices for Saudi customers have to be in Arabic?
Yes. Saudi VAT regulations require tax invoices to be in Arabic, and other languages may be included alongside it. This applies to the invoice content as presented to the customer, so systems issuing invoices for Saudi Arabia need dependable Arabic text and PDF generation.
Which frameworks are best for Arabic web applications?
Next.js and Laravel both support Arabic and RTL well. What matters more is how the interface is built: CSS logical properties, proper localization libraries, server-side rendering of the correct direction, and Arabic-capable fonts and PDF tools.
How do we support Arabic and English in the same application?
Use locale-based routing or a user setting to choose the language, set the lang and dir attributes accordingly, store translatable content in both languages, and build layouts with logical properties so the same components work in both directions.
Is machine translation good enough for an Arabic interface?
It can help with a first draft, but it should not be the final step. Interface text, legal content, and marketing copy should be reviewed by a native Arabic speaker, both for accuracy and to match the tone expected by users in the region.
Conclusion
Arabic and RTL support is a core requirement for software that serves the Gulf, not a cosmetic extra. Building it well means designing layouts with logical properties, mirroring what should mirror and protecting what should not, handling mixed text, choosing proper Arabic typography, formatting numbers and Hijri dates correctly, and producing reliable Arabic documents. Next.js and Laravel both provide strong foundations for this work. If you are planning a bilingual application for the UAE, Saudi Arabia, or the wider region, our team builds Arabic and English interfaces that feel native in both directions from day one.