A sentence such as “Send the form to مكتب لندن (London Office), room 12” can look different from the order in which someone typed it. The Arabic phrase runs right to left, the English words and digits run left to right, and punctuation has to find a place among both. When that display goes wrong, a reader may misunderstand a name, address, or instruction even though every word is present.
Bidirectional text, often shortened to bidi text, is text that combines left-to-right and right-to-left writing directions. English and Arabic in the same paragraph are a familiar example. The fix isn’t to reverse the Arabic characters or rearrange words by hand. The fix starts with understanding how the text’s underlying order differs from its visual presentation.
What bidirectional text is and why it looks confusing¶
Bidirectional text is text whose characters belong to writing systems with different directions, such as Arabic and English, in the same line or paragraph. Arabic script is written right to left. English is written left to right. A line containing both can therefore have directional runs that appear in different visual orders.
A run is a stretch of text that follows one direction. In a mixed Arabic-English sentence, an Arabic phrase may form one run, a Latin product name another, and a number a third. The Unicode Bidirectional Algorithm, or UBA, calculates how those runs appear on screen. The characters remain stored in logical order, meaning the order in which a person reads or enters them, rather than being physically rearranged in the underlying text. Unicode describes the algorithm in Unicode Standard Annex #9.
As the Unicode Consortium’s bidirectional text FAQ puts it: “The Unicode Bidirectional Algorithm, often abbreviated to just “UBA”, explains in detail how text should be laid out in lines whenever it consists of a mixture of left-to-right script characters and right-to-left script characters.”
The practical point is that visual order isn’t a reliable guide to the order of the stored characters. A text editor, browser, or document app can display the same logical sequence according to its direction rules. Copying what appears on screen and trying to reconstruct it by hand can introduce new errors.
The UBA assigns characters directional types. Strong characters have a clear left-to-right or right-to-left direction. Many number-related characters are weak, meaning their direction needs more context. Punctuation and other symbols are often neutral. The algorithm uses these properties and the paragraph’s base direction to determine a visual arrangement. The current standard described here is Unicode 18.0.0, retrieved 2026-10-08, in UAX #9.
A paragraph’s base direction is its overall starting direction. That direction helps determine how runs are ordered and how neutral characters at run boundaries are resolved. A block of Arabic text will usually need a right-to-left base direction; a block of English needs a left-to-right one. The words don’t need to change just because the base direction does.
This distinction helps diagnose apparently similar problems that have different causes. If a whole Arabic paragraph aligns or flows like an English paragraph, its base direction may be wrong. If only one name, email address, or punctuation mark looks out of place, the inline text may need its own direction or isolation. Those are separate fixes, even when both symptoms show up in one sentence.
The algorithm also applies when text appears to use only one script but includes numbers or symbols whose behavior interacts with the paragraph direction. A phone number in an Arabic paragraph, for example, still has its own left-to-right sequence. A line doesn’t need a long English phrase to become bidirectional. Arabic text mixed with Latin numerals can be enough to require the algorithm’s rules.
A common trap is to treat visual order as the source text. Reversing an Arabic character sequence to make it look right can produce text that displays incorrectly elsewhere, is hard to search, or no longer behaves as intended when copied. Keep the characters in their logical order and set the appropriate direction for the context.
Why punctuation and numbers appear to move¶
Punctuation looks like a small detail, but it is often the first visible sign that mixed-direction text hasn’t been given the right context. A period, comma, colon, or bracket may not have an inherent left-to-right or right-to-left direction. The bidi algorithm therefore resolves its placement by examining nearby text and the paragraph’s base direction.
The Unicode Consortium explains this behavior in its bidirectional text FAQ: most punctuation and symbols are neutral, and their visual direction depends on the surrounding text. A period at the end of an English phrase inside an Arabic paragraph can consequently appear to belong to a different run than the writer intended.
Consider a label that combines an Arabic instruction with an English file name. The file name may contain a period and an extension, while the sentence around it uses Arabic punctuation and direction. Without clear boundaries, a reader’s screen may place one of those marks unexpectedly. The underlying characters haven’t necessarily changed; the display algorithm has resolved neutral characters using the surrounding directional context.
Numbers add another layer. A sequence of digits can keep its own left-to-right appearance inside Arabic text, while punctuation around it is resolved from context. A date, phone number, or reference code can therefore look confusing even when all digits appear in the expected order. The punctuation adjacent to the digits may be the part that shifted.
The paragraph’s base direction matters because it gives the algorithm a context for arranging runs and neutral characters. Setting the correct base direction can fix a display problem without altering a single word. MDN’s guidance on the dir attribute, retrieved 2026-10-08, explains that direction supplies this base context.
A useful debugging sequence is to check the broad context first, then the local phrase:
- Identify the paragraph’s intended reading direction.
- Check whether the paragraph or containing block declares that direction.
- Find the exact boundary where English, Arabic, digits, or punctuation meet.
- Mark a known-direction inline phrase explicitly, or isolate unknown-direction text.
- Check the rendered result in the context where readers will actually see it.
The order matters. Adding special handling to a product name won’t correct an entire block whose base direction is wrong. Conversely, changing a whole page to right-to-left just to fix one English email address can disturb other content. Match the scope of the direction setting to the scope of the problem.
A separate issue comes from punctuation that belongs to a phrase but sits outside its directional markup. When an inline phrase’s direction is known, wrap the complete phrase, including punctuation that belongs to it, in the element with the appropriate direction. A boundary placed between the phrase and its punctuation can leave the mark exposed to the surrounding paragraph’s rules.
MDN describes
diras an attribute that sets an element’s base direction and isolates its contents directionally from surrounding text in its reference for thedirglobal attribute.
That description points to two useful jobs: setting the base direction and creating a boundary around content. A developer who uses dir on the right element can often fix ordering without editing the actual text. A translator who sees the issue in a document can flag the direction context rather than rewriting or reversing a phrase.
Choosing dir, dir=”auto”, and bdi in HTML¶
HTML provides direction attributes and elements so web pages can express how text should behave. The main choices are dir="rtl", dir="ltr", dir="auto", and the bdi element. The right choice depends on whether the direction is known and whether the text is a block or an inline value.
Use dir="rtl" on a block whose base direction is right to left. For an Arabic-first page, set the direction on the root html element, then use nested direction settings when a particular block differs. Use dir="ltr" for a known English passage inside an Arabic page. MDN’s directionality attribute reference, retrieved 2026-10-08, describes this pattern.
The lang attribute and the dir attribute have different jobs. The lang value identifies a language; it doesn’t set the text direction by itself. An element can declare Arabic as its language and still need dir="rtl" to establish direction. A page can also contain English text that needs its own direction even when the surrounding page is Arabic.
Use dir="auto" when incoming text has an unknown direction. The browser determines the base direction from the content, generally using the first strongly directional character. This setting is intended for unknown-direction data, such as content entered by a user or supplied from an external source.
Auto is a heuristic, not language detection. A string that begins with an English name and then continues in Arabic can receive a left-to-right base direction because the first strong character is English. If the direction is known from the surrounding data model or interface, set it explicitly instead of asking auto to infer it.
The bdi element is for a span of text that needs to be isolated from the text around it. The name refers to bidirectional isolation. Text inside the element doesn’t influence the directional ordering outside it, and the surrounding text doesn’t influence the ordering inside it. The HTML Standard identifies unknown-direction, user-generated content as a key use case for bdi.
For example, a page might show an Arabic sentence followed by a name taken from a user profile. The name could be in English, Arabic, or a mixture. Wrapping the name in bdi protects the sentence around it from that value’s direction and protects the value from the sentence’s direction.
<p dir="rtl">
مرحبًا، <bdi>Alex Smith</bdi>!
</p>
When a bdi element has no dir value, it behaves as though dir="auto" were set. That default makes it useful for inline values whose direction isn’t known until the content arrives. MDN documents this behavior in its bdi element reference, retrieved 2026-10-08.
Use explicit dir on an inline element when the phrase’s direction is known. Keep the complete phrase together, including punctuation that belongs to it. This gives the browser a clear boundary and a clear direction, instead of making it infer both from neighboring text.
| Situation | Suitable choice | Why |
|---|---|---|
| Arabic paragraph or page | dir="rtl" |
Declares a known right-to-left base direction |
| English block inside an Arabic page | dir="ltr" |
Declares a known left-to-right base direction |
| User-provided value with unknown direction | bdi or dir="auto" |
Lets the browser infer direction while containing its effects |
| Inline phrase with known direction | An element with explicit dir |
Sets a known direction at the right scope |
| Text language known but direction not declared | Add dir as well as lang where needed |
Language metadata doesn’t set direction |
HTML’s dir attribute is preferable to styling direction with CSS when possible because direction belongs to the meaning and behavior of the text. Semantic markup continues to convey that information if CSS isn’t available or is disabled. CSS’s direction property sets a block-level base direction and affects alignment and table or grid cell flow; its effect on inline-level elements depends on unicode-bidi. MDN covers that distinction in its CSS direction reference, retrieved 2026-10-08.
A practical implementation can use both semantic direction and layout styling, but the roles shouldn’t be confused. Use HTML to say what direction the text follows. Use CSS for visual styling and layout. Applying a visual workaround without setting semantic direction can leave the text’s bidi behavior unclear to browsers and tools.
When bidirectional isolation helps¶
Isolation matters when a short phrase or value appears inside a longer sentence and its direction shouldn’t change the sentence around it. Typical examples include a name, username, product code, email address, quoted phrase, or value supplied by a user. The content might be English inside Arabic, Arabic inside English, or mixed itself.
Unicode defines isolate controls called LRI, RLI, FSI, and PDI. They mark the beginning and end of an isolated range, preventing characters inside that range from affecting ordering outside it and vice versa. Unicode introduced directional isolates in Unicode 6.3 because embeddings could have too strong an effect on surrounding text. The current guidance in UAX #9 encourages isolates rather than embeddings when target platforms support them.
The Unicode Consortium states in UAX #9: “Characters within an isolate cannot affect the ordering of characters outside it, or vice versa.”
On the web, bdi supplies an HTML-level way to express that boundary. For known direction, an element with an explicit dir value can isolate the complete phrase. For unknown direction, bdi or dir="auto" can handle the value without guessing in the translation itself.
A useful example is a notification template. The fixed message might be Arabic, while a customer name arrives from a database. The template author knows the surrounding sentence’s direction but may not know the name’s direction. Isolating the name prevents its first strong character from changing how nearby punctuation or words appear.
Isolation also helps when a value contains punctuation. A username might include a period or hyphen; an email address has punctuation with meaning inside the address. A code can contain letters, digits, and separators. Treating the whole value as one isolated unit gives the rendering system a clearer boundary than leaving the value’s marks exposed to the surrounding sentence.
The boundary must match the content. If punctuation belongs to the inline phrase, include it within the directionally marked span. If punctuation belongs to the surrounding sentence, leave it outside. That distinction is editorial as much as technical: the markup should reflect which words and symbols form a single phrase.
Unicode directional controls and HTML markup aren’t interchangeable in every context. Unicode says explicit directional formatting characters should be replaced by mechanisms suitable for HTML and CSS in web pages. For web content, use semantic elements and attributes rather than scattering invisible controls through the text. UAX #9 gives this guidance for web pages.
Directional controls can be relevant in plain-text environments where markup isn’t available, but they should be introduced deliberately. A translator shouldn’t insert invisible characters as a generic repair for every punctuation issue. The controls affect display ordering, but Unicode says they don’t change text comparison, word breaks, parsing, or numeric analysis. A visual fix therefore doesn’t automatically change how other software interprets the underlying text.
The choice is especially important when text passes through multiple systems. A browser may understand HTML markup, while a plain-text export may not preserve that boundary in the same way. A document editor may display direction controls invisibly. A text-processing system may compare the logical character sequence rather than its visual appearance. Keep the source content logical, then choose a direction mechanism that fits the destination.
When bidi markup isn’t the right fix¶
Not every English-Arabic display issue needs special markup. A paragraph made entirely of Arabic may render correctly once its base direction is set. An English paragraph inside an Arabic document may need a known dir="ltr" setting, but not an isolate if it’s already a separate block. Extra direction controls can make content harder to inspect without solving a real problem.
The first question is whether the direction is known. If the whole block is known to be Arabic, set rtl. If the block is known to be English, set ltr. If the value comes from unknown external content, use bdi or dir="auto". Applying auto to text with a known direction can add uncertainty rather than remove it.
The second question is whether the issue affects a block or a phrase. A block-level problem needs a block-level direction. An inline problem needs an inline boundary. Changing the entire page direction to fix one embedded English code can create new issues elsewhere, while isolating that code keeps the fix local.
The third question is whether the characters are in the right logical order. A display bug can tempt someone to reverse Arabic text manually. That approach is unsafe because the UBA is designed to calculate display order from logical text. Reversed storage can become visibly wrong in another application or when the text is copied into a field with different direction settings.
Translators should also avoid inserting directional controls into translated prose as a substitute for markup when the destination is a web page. A translation should preserve the intended words and punctuation. Developers should apply direction and isolation where the content is rendered, using HTML that communicates the text’s direction.
A text-only channel may have no HTML support. In that case, the writer has fewer tools, and the handling depends on the system that displays the text. Unicode defines explicit controls, including isolates, but they should be used with knowledge of how the receiving platform handles them. The source text shouldn’t be rearranged simply to imitate one particular screen’s visual output.
A further reason to avoid casual control insertion is that bidirectional text can create visual-confusion risks. The logical character sequence and the displayed appearance can differ, which can be abused to make text appear misleading. Unicode’s security report discusses bidirectional text spoofing and advises software that handles Unicode text to consider those risks in Unicode Technical Report #36. That report is longstanding conceptual security guidance, published 2010-08-04, not a current measurement of threat frequency.
For interfaces that display user-provided strings, isolation is a formatting measure, not a substitute for validating or safely handling input. A value can be visually confusing even when its characters are valid. Keeping the value within a bidi boundary makes the surrounding interface more predictable, while other input-handling decisions remain separate.
Unicode’s web guidance in UAX #9 says that explicit directional formatting characters should be replaced by mechanisms suitable for HTML and CSS in web pages.
The takeaway is simple: don’t make the stored text imitate the screen. Keep the logical sequence intact, set the base direction for the relevant block, and isolate a phrase only when its relationship with surrounding text calls for it.
FAQ¶
How do you keep Arabic and English text in the right order in a translation?¶
Keep the characters in logical reading order and set the correct base direction for the paragraph or inline phrase. On the web, use dir="rtl" for Arabic blocks, dir="ltr" for English blocks, and bdi or dir="auto" for inline content whose direction is unknown. The Unicode Bidirectional Algorithm handles the visual ordering.
Why does punctuation move when Arabic and English are mixed?¶
Most punctuation is directionally neutral, so its displayed position depends on nearby directional characters and the paragraph’s base direction. The Unicode Consortium’s bidi FAQ explains why punctuation can appear misplaced in mixed Arabic-English text. Correct direction settings and boundaries often fix the display without changing the words.
When should a web page use dir=”rtl”, dir=”ltr”, or dir=”auto”?¶
Use dir="rtl" for a known right-to-left block and dir="ltr" for a known left-to-right block. Use dir="auto" when incoming content has an unknown direction, such as a user-provided value. Auto follows the first strongly directional character, so it isn’t language detection; use an explicit direction when you know it.
How does the HTML bdi element prevent mixed-direction text from breaking?¶
The bdi element isolates its contents from surrounding bidirectional text. The inline value doesn’t affect the ordering outside it, and the surrounding sentence doesn’t affect the value. With no dir value, bdi behaves as though dir="auto" were specified, as MDN explains in its bdi reference.
Should translators insert Unicode bidirectional control characters into translated text?¶
Usually not for web pages. Unicode recommends HTML and CSS mechanisms such as dir and bdi for web content instead of scattering invisible directional controls through the text. Keep the translated characters in logical order and let the web markup express direction.