Arabic RTL Layout: Fixing Direction and Formatting Issues

An Arabic translation can be correct word for word and still look wrong: a bracket moves, an English product name jumps to the other end of a sentence, or a number appears beside the wrong label. The problem often isn’t the translation. It’s how the page handles text that runs in two directions.

Arabic right-to-left layout is not a matter of flipping every element horizontally. You need to handle paragraph direction, embedded Latin text, numbers, punctuation, component flow, and icons according to what each one means. Once those layers are separated, layout problems become easier to diagnose and test.

What Arabic RTL layout means¶

Right-to-left, or RTL, describes the direction in which a writing system’s text generally progresses across a line. Arabic is written from right to left, so an Arabic paragraph usually begins on the right. English is left to right, or LTR, and its paragraph usually begins on the left.

The distinction sounds simple until both scripts appear together. An Arabic sentence may include an English brand name, a web address, a reference number, or a date. Digits are written left to right, even when they appear within Arabic text. Unicode describes that combination as bidirectional text: a line can contain directional runs that follow different rules.

As the Unicode Consortium explains: “Whenever right-to-left scripts, for example, use digits that are written from left to right, the text is actually bidirectional: a mixture of right-to-left and left-to-right text, even in the same script.”

That point changes the way you should approach an Arabic layout. The goal isn’t to force every character to face one direction. The goal is to tell the browser or document renderer which parts belong together, then let the bidirectional rules display them in the right visual order.

Logical text order and visual order aren’t the same¶

A computer stores text in a logical sequence: the order in which the words and characters belong. A screen then applies directional rules to decide where each character appears visually. The Unicode Bidirectional Algorithm, usually shortened to UBA, determines display ordering from character properties. It doesn’t reverse the stored text.

That separation explains why copying Arabic text from a page can sometimes produce a sequence that looks different from the line you saw. The underlying characters may still be stored in logical order, while the display engine arranges them for reading. A translation workflow that assumes the visible left-to-right position is the stored text order can therefore damage a sentence or move punctuation into the wrong place.

Punctuation makes the difference especially visible. A comma, parenthesis, colon, or slash may sit between a right-to-left phrase and a left-to-right word or number. Some marks don’t have a strong direction of their own. The surrounding characters influence where the mark appears, so a line that seems obvious to a reader can still be ambiguous to a rendering system.

Text direction isn’t alignment¶

Direction and alignment often get mixed up, but they answer different questions. Direction describes the flow and ordering behavior of text. Alignment describes where content sits within its available space.

A right-aligned English paragraph is still English text with LTR direction. An Arabic paragraph can also be right-aligned, but its direction is RTL as well. Changing alignment alone won’t solve bidirectional ordering problems, and applying RTL direction to an English paragraph can introduce new punctuation issues.

The CSS direction property affects more than the position of words. MDN documents effects on block text’s base direction, default alignment, table and grid cell flow, and horizontal overflow. MDN recommends using the HTML dir global attribute instead of CSS direction where possible. The HTML attribute expresses direction as part of the content’s meaning; a styling rule alone doesn’t convey that semantic context.

Shaping is another part of Arabic text display¶

Arabic letters can change shape depending on their position and the letters around them. A font and text-rendering system shape those characters so connected forms appear as intended. Text shaping and bidirectional ordering are related parts of rendering, but they’re different jobs: shaping chooses how characters are drawn, while the bidi algorithm determines their visual order.

A font problem can make Arabic look disconnected, crowded, or visually inconsistent even when the direction is correct. A direction problem can place a Latin product name or punctuation incorrectly even when the font shapes Arabic well. Checking these separately prevents a team from trying to fix one problem with a setting that affects another.

How bidirectional Arabic text works in practice¶

The Unicode Bidirectional Algorithm gives a renderer a set of rules for working out visual order. Most text displays without extra directional controls. Special mixed-direction cases can need more explicit boundaries, because a browser or document reader may not know which surrounding phrase a punctuation mark belongs to.

A useful mental model is to treat a paragraph as a flow with smaller runs inside it. The Arabic sentence supplies the main right-to-left direction. An English term, URL, or code can form a left-to-right run within that sentence. When the boundaries are clear, the renderer can lay out the runs without changing the words themselves.

Set direction at the right level¶

For a web page, mark Arabic content with HTML’s dir attribute when that content is meant to read right to left. A block of Arabic might use dir="rtl"; an English passage in an otherwise Arabic page may use dir="ltr".

Direction belongs on the semantic region that needs it, not indiscriminately on every container. A whole interface may use an RTL base direction, while a specific email address, code sample, or English quote needs its own LTR treatment. Applying RTL to a mixed-language block that contains English prose can move punctuation in surprising ways.

MDN’s logical properties guide puts the layout problem simply: “The start of a line is not always the left side of a line.”

For an RTL line, the inline start is on the right. That matters when a developer lays out icons, labels, and controls using fixed physical sides. A left margin that looks sensible in English may belong on the opposite side in Arabic. Direction-aware layouts describe the relationship to the text flow instead of assuming the same physical side will always be correct.

Isolate embedded text when boundaries are unclear¶

A short Latin string inside Arabic may display correctly without special handling. A code, a URL, or text next to punctuation can be less predictable because the renderer has to decide where the left-to-right run starts and ends.

Unicode defines directional marks such as LRM, RLM, and ALM, along with embedding, override, and isolate controls. Isolate controls include LRI, RLI, FSI, and PDI. Their purpose is to make directional boundaries explicit. An isolate keeps its contents from affecting the ordering of surrounding text, unlike embedding content, which can influence ordering across the boundary.

Unicode encourages using isolates rather than embeddings in new documents when the target platform supports them. Web pages should generally use suitable HTML and CSS mechanisms instead of inserting explicit formatting characters everywhere. Semantic markup makes the structure easier to inspect and maintain, while invisible controls can be hard to spot in an editor or when debugging copied text.

For a web interface, the HTML <bdi> element can mark a span whose direction should be isolated from its surroundings. A translation system may also need to preserve placeholders and codes as separate spans. The practical choice depends on the platform, but the principle stays the same: give mixed-direction content a clear boundary instead of applying a broad direction rule to the whole line.

Use CSS that follows text flow¶

Physical CSS properties such as margin-left, padding-right, left, and right assume a fixed screen side. Those assumptions often break when the same component changes from LTR to RTL. CSS logical properties instead describe relationships to the writing flow.

Terms such as inline-start, inline-end, block-start, and block-end refer to the content’s direction and writing mode. In horizontal RTL text, inline start and inline end map to the opposite physical sides from their LTR equivalents. A component using logical properties can adapt without needing a separate left-side and right-side rule for every translated version.

Microsoft’s guidance also warns against relying on absolute positioning and fixed widths or heights where possible. Translated text changes the space a label needs. A layout that can grow and reflow is less likely to cut off a longer Arabic label or overlap a neighboring control.

Microsoft Learn advises: “Instead, take advantage of the dynamic layout mechanisms that are built into the Windows UI elements.”

For a web or app team, the transferable lesson is to let text size and flow shape the component. Avoid pinning every label to a coordinate, especially in forms, menus, and cards that will contain translated text. Use flexible spacing and symmetrical padding where suitable, and confirm that controls inherit the intended flow from a root layout or page.

Choose number formats deliberately¶

Arabic interfaces don’t all use the same digits. Unicode CLDR’s Arabic locale chart lists two numbering systems: latn, the default shown in that chart, and arab, the native system. The chart’s arab examples use Arabic-Indic digits and Arabic grouping and decimal marks, including ١٬٠٠٠ and ١٫٥; its latn examples retain Latin digits and punctuation.

Those examples show why a team shouldn’t assume that an Arabic translation means every number should change to Arabic-Indic digits. The right choice depends on the audience, product conventions, and the kind of information being shown. A financial value, phone number, account identifier, and date may each have different expectations. Keep the value’s meaning clear, and check that the chosen digits and separators display in the intended order.

The bidi algorithm handles directional display, but it doesn’t decide which locale’s number format is right for a particular product. Localization teams need to make that choice explicitly. A format that appears familiar to one group of users may be harder to read or enter for another.

When Arabic RTL handling is needed¶

RTL treatment matters anywhere Arabic is the language of the interface or document. That includes websites, mobile apps, forms, help content, dashboards, PDFs, tables, subtitles, and emails. A small text sample may look fine while a full screen exposes the real trouble: longer labels, nested menus, mixed-script fields, and buttons positioned on the wrong side.

Web pages and applications¶

A page localized into Arabic needs more than translated strings. The team must set the page or content region’s direction, make components adapt to the flow, and check the behavior of every mixed-direction string. Navigation order, breadcrumbs, tabs, pagination, side panels, search fields, and form controls all deserve a visual review.

Use the dir attribute for content direction where possible. Use CSS logical properties for spacing and positioning. Then inspect the result with real Arabic text rather than a placeholder or a single short label. A design that looks correct with one word may fail when a label wraps or a validation message contains an English term.

Direction also needs to reach the controls that depend on it. Microsoft says a developer must set flow direction appropriately for the displayed language; changing the operating system’s display language doesn’t automatically change an app’s flow direction. A page-level or root-panel setting can help contained controls inherit a consistent base flow, while specific text runs can override that direction where their meaning requires it.

Documents, forms, and tables¶

An Arabic document can contain right-to-left prose alongside left-to-right dates, numbers, web addresses, or reference codes. Forms add another layer: a label may be Arabic while the value is a phone number or email address. A table can also mix Arabic headings with numeric columns, Latin product names, and punctuation.

Check the direction of each cell, not just the document as a whole. A table’s column order may need to follow Arabic reading flow, but an identifier inside a cell may still need LTR direction. A heading aligned on the right doesn’t automatically fix the order of content inside every row.

Tables also reveal a difference between visual order and data order. A reader might expect the first column to appear at the right in an RTL presentation, while a data export or form model still stores fields in a logical sequence. Preserve a clear relationship between a field label and its value, and verify that copying or exporting the information doesn’t silently change that relationship.

Which interface elements should mirror?¶

Mirroring means reversing a component’s left-right presentation to suit a different reading or navigation direction. Some interface elements should mirror; others should not. Treating RTL as a blanket horizontal flip can make a screen more confusing rather than more local.

Microsoft’s mirroring guidance distinguishes controls that can mirror, such as pull-down buttons, from directional media icons such as fast-forward and rewind, which should keep their orientation. The same reasoning applies more broadly: ask what an icon represents before reversing it. An arrow showing movement through a right-to-left reading sequence may need to change. An icon representing a real-world object or a fixed action may not.

A review should therefore consider separate questions:

• Does the text flow in the right direction?
• Does the component’s order match the reading sequence?
• Does the icon indicate reading direction, movement, or a fixed action?
• Does the control still communicate the same function after mirroring?
• Can a user reach and operate the control comfortably in its new position?

Microsoft’s bidi design checklist includes UI mirroring, a consistent RTL experience, touch optimization, and support for mixed-direction text. Those are separate checks, not a single flip switch. A screen can have RTL text and still feel inconsistent if controls, navigation, and touch targets follow conflicting rules.

For more on preserving the visual structure of translated documents, see how to preserve formatting in Word, PDF, and Excel translations. Teams working with Arabic tables can also use the practical checks in the guide to preserving tables when translating DOCX files.

When full RTL mirroring isn’t needed¶

Not every Arabic page or document needs every element reversed. A document containing one Arabic paragraph inside an English report may need a right-to-left text region, not a full-page RTL layout. A bilingual page may need separate directional regions, each with its own reading order.

The right question isn’t “Should this screen be flipped?” It’s “Which content, component, or interaction follows the Arabic reading flow?” A short Arabic quotation in an otherwise English article doesn’t automatically make the article’s navigation, charts, or buttons RTL. Likewise, an Arabic interface can still contain LTR content such as a code sample or a web address.

Separate direction, alignment, and component flow¶

A layout may need RTL text direction without mirrored icons. Another layout may need a navigation sequence to start on the right while keeping certain charts, media controls, or diagrams in their original orientation. Treat these choices as independent instead of using one global setting to control everything.

For a bilingual website, define the language and direction for each language region. Keep an English passage LTR even when it appears within an Arabic page, and keep Arabic passages RTL when they appear in an English page. A semantic boundary helps assistive technologies and rendering engines understand the change as well as helping the visual layout.

Preserve meaningful visual conventions¶

Some content has a direction that comes from its function rather than the surrounding language. A timeline, playback control, measurement scale, or diagram may encode a sequence or orientation that shouldn’t be reversed automatically. Review the meaning of the graphic before mirroring it.

Charts need particular care. Text labels may need RTL treatment, while the plotted data and axis values may need to preserve a consistent measurement convention. Reversing labels without checking the relationship between each label and its data point can mislead users.

A technical document can also include source code, formulas, or identifiers that should remain in a fixed order. Give those regions an explicit direction where necessary, and avoid changing their characters to make the page look symmetrical. The goal is readability without altering the data.

Don’t add invisible controls as a default fix¶

Directional formatting characters can help with a specific ambiguous string, but scattering invisible characters through translated copy makes content harder to maintain. Editors may not show those characters clearly. A later text change can also leave an isolate or mark in the wrong place.

Start with semantic structure and platform-supported direction settings. Use explicit formatting characters only when the content and target platform call for them, and test the result in the actual renderer. Unicode’s guidance on isolates is useful here: isolates create boundaries around directional runs, but the web usually has appropriate markup and styling mechanisms for expressing the same intent.

A translator should not be expected to repair a layout by inserting hidden marks into every sentence. The localization workflow should preserve the text and identify ambiguous runs, while the implementation should set direction at the right structural level.

Common Arabic RTL layout failures and how to check them¶

RTL problems often appear only in mixed content. Arabic-only text may render smoothly, so a quick glance at a translated heading can give a false sense that the interface is ready. A stronger review uses deliberately awkward examples: Arabic next to an English term, a number at the start of a line, or a URL followed by punctuation.

A reported Markdown renderer issue describes English text appearing on the wrong visual side of Arabic text. The report is an individual bug report, not evidence that the same failure affects every renderer. Its value is practical: it shows the kind of symptom teams should reproduce and test rather than assuming all display engines handle every mixed-direction case identically.

The GitHub issue reporter described the failure this way: “Words appear reordered visually. The English word world ends up on the wrong side of the Arabic text.”

A misplaced English word doesn’t automatically mean the translation is wrong. Check the paragraph’s base direction, the boundaries around the English run, and the renderer being used. If the same text behaves differently across a browser, a Markdown preview, and a PDF, the problem may be in the rendering path rather than the source sentence.

Common mistakes to look for¶

Applying RTL to an entire mixed-language paragraph. A page-level RTL setting may be appropriate for an Arabic interface, but an English sentence inside that page still needs to retain its own direction. Applying RTL to that English sentence can move punctuation in ways the writer didn’t intend. Set direction on the smallest meaningful region that needs it.

Using alignment as a substitute for direction. Right-aligning text doesn’t tell the renderer how to order mixed-direction runs. A paragraph can be aligned to the right and still need a clear direction setting. Check alignment and direction separately.

Hard-coding left and right positions. A component built around left, right, or physical margin values may stay on the wrong side in RTL. Use logical properties when the layout should adapt to reading flow, then inspect any element whose position carries meaning.

Flipping every icon. A mirrored play or navigation symbol can suggest the wrong action if its orientation represents a fixed direction. Review each icon’s meaning, not just its shape.

Assuming every number uses the same digits. CLDR’s Arabic chart shows both latn and arab numbering systems, so a localized interface shouldn’t infer one universal choice from the language alone. Decide how each product context handles digits, grouping, and decimal marks, then test input and display.

Testing only short, Arabic-only samples. A line with no English text, digits, brackets, or URL won’t reveal many bidi errors. Use test content that forces the layout to handle conflicting directional runs.

A practical RTL localization test set¶

Run the following cases through the actual browser, app, document editor, or export process used by readers. Don’t rely on a source editor preview if the published renderer behaves differently.

1. An Arabic-only paragraph, to confirm that the baseline direction and shaping look right.
2. An Arabic paragraph beginning with Latin text or a number, to test how the first visible run is placed.
3. An Arabic sentence with an embedded English product name, to check run boundaries.
4. A URL in an Arabic paragraph, especially when punctuation follows it.
5. Parentheses, commas, colons, slashes, and quotation marks beside mixed-direction text.
6. A numbered list, to check list markers, indentation, and the position of the text.
7. A table with Arabic labels, Latin identifiers, and numeric values in neighboring cells.
8. A form field where the label and entered value use different scripts.

These cases follow the types of mixed-direction failures discussed in Unicode guidance and the cited renderer report. They aren’t a claim that every platform will fail every case. They’re a repeatable way to expose ambiguity before a page or document reaches users.

Record what you expect to happen before testing. For example, note whether a URL should remain LTR, which side a list marker should occupy, and whether parentheses should enclose the English term visually. A written expectation helps teams distinguish a real defect from a deliberate layout choice.

A short debugging sequence¶

When an English word or punctuation mark appears on the wrong side, inspect the problem in a consistent order:

1. Check the language and direction on the containing element. Confirm that Arabic text is marked RTL and English content is marked LTR where appropriate.
2. Find the smallest mixed-direction run. Look for a brand name, number, email address, URL, or code immediately beside the misplaced mark.
3. Check the run boundary. Use suitable semantic markup or an isolate mechanism when the renderer can’t infer the intended boundary.
4. Review CSS positioning. Replace physical left-right assumptions with logical properties where the component should follow text flow.
5. Test the actual output. Compare the browser or app with any exported PDF or document; separate renderers can display the same content differently.
6. Copy and re-enter the text. Check that the stored logical order remains correct and that copying doesn’t introduce an unintended sequence.

Unicode’s Bidirectional Algorithm guidance explains that isolate content cannot affect the ordering of surrounding text, unlike embedding content, which can influence ordering across its boundary.

That distinction is especially useful when debugging a span that contains English text inside Arabic prose. The fix should protect the surrounding sentence from the embedded run, not force the entire paragraph into one direction. Keep the intervention local, then rerun the mixed-content test set.

For a separate look at file-level layout problems during translation, read how to translate a PDF without losing its formatting. The same habit applies to Arabic RTL work: inspect the final rendered file, not only the text extracted from it.

FAQ¶

Why does English text or punctuation move to the wrong place in Arabic translations?¶

Arabic and Latin text follow different directional behavior, and punctuation can be ambiguous between them. The Unicode Bidirectional Algorithm uses character properties to determine display order, but a mixed-direction run may need semantic markup or a directional isolate to make its boundaries clear.

How do you fix mixed Arabic and English text in an RTL document?¶

Set the Arabic paragraph’s direction, then isolate embedded English terms, codes, or URLs when the surrounding context remains ambiguous. On a web page, use semantic HTML such as dir and <bdi> where appropriate, and test the text in the renderer that will show it to readers.

Should an Arabic website use dir=”rtl” or CSS direction: rtl?¶

Use HTML’s dir="rtl" to express Arabic content direction where possible. CSS direction affects more than text alignment, including block flow and table or grid behavior, so it shouldn’t be treated as a simple right-alignment switch.

Which interface elements should be mirrored for Arabic RTL layouts?¶

Mirror elements whose position or order depends on the reading or navigation direction, but don’t flip every icon automatically. Microsoft distinguishes controls that may mirror, such as pull-down buttons, from directional media icons such as fast-forward and rewind, which keep their orientation.

How should numbers, dates, and currency be displayed in Arabic layouts?¶

Choose the numbering system and formatting conventions for the audience and product context. CLDR’s Arabic chart lists both latn and arab systems, with different digit and punctuation examples, so don’t assume every Arabic interface should use the same digits.

Why does an Arabic page look right in a browser but wrong in a PDF?¶

A browser and a PDF renderer may handle the same mixed-direction text through different layout paths. Check the content direction, the boundaries around embedded Latin text, and the exported file itself; a correct browser preview doesn’t prove that the PDF will display identically.

Should every icon and navigation control be flipped for Arabic?¶

No. Check whether each element follows reading direction or represents a fixed action or real-world orientation. Microsoft advises selective mirroring, so navigation controls may change while icons such as fast-forward and rewind retain their direction.