The Unicode Bidirectional Algorithm, explained

The Unicode Bidirectional Algorithm (UBA) is the set of rules that turns stored text into the order a reader sees when right-to-left and left-to-right writing share a line. The current text is Unicode Standard Annex (UAX) #9, revision 52, dated September 1, 2026, for Unicode 18.0. Unicode stores characters in logical order, the order in which they are read. Arabic and Hebrew display right to left, and the annex notes that once such text includes digits, which are written left to right, it is bidirectional. Embedded English words have the same effect.

Logical order and display order

The annex is explicit that the characters are still interpreted in logical order and only the display is affected. The algorithm runs in four phases: it splits text into paragraphs, assigns each character its bidirectional type, resolves an embedding level for each character, and then reorders each line for display. Paragraphs do not affect each other, and a higher-level protocol can define them. Two cells of a table, the annex says, are two paragraphs.

An article from the World Wide Web Consortium (W3C), Unicode Bidirectional Algorithm basics, by Richard Ishida, first published in 2013 and last substantively updated in 2016, states the practical consequence. In all major web browsers, the order of characters in memory is not the order on screen. The display depends on the base direction of the paragraph or phrase. The same characters, in the same memory order, show their directional runs in reverse order when the base direction changes from left-to-right to right-to-left. The article adds that most applications treat text as left-to-right by default.

Numbers and Latin text in a right-to-left line

Every character has a bidirectional type. Letters are strong: left-to-right for Latin, right-to-left for Arabic and Hebrew. Most numbers are weak, and spaces and punctuation are neutral.

The W3C article shows what that means. European digits, 1234, and Arabic-Indic digits, ١٢٣٤, both read left to right. Because they are weak, two Arabic words on either side of a number stay in one right-to-left run. A currency symbol next to a number is treated as part of the number. A neutral character between runs of opposite direction takes the base direction, so an exclamation mark after an Arabic title in a left-to-right paragraph lands on the wrong side. In another example, "W3C" must appear to the left of the Hebrew text it accompanies. With a left-to-right default it appears to the right, which the article says can significantly change the meaning.

Some characters change shape with direction. UAX #9 notes that U+0028, named LEFT PARENTHESIS, really expresses an open parenthesis, and the W3C article shows one angle bracket pointing right in left-to-right text and left in right-to-left text.

The directional formatting characters

When the implicit rules are not enough, UAX #9 defines invisible characters to control the order:

Characters	Code points	Effect
LRM, RLM, ALM: left-to-right, right-to-left, and Arabic letter marks	U+200E, U+200F, U+061C	Zero-width marks that act as a strong character
LRE, RLE: left-to-right and right-to-left embedding	U+202A, U+202B	Start an embedding
LRO, RLO: left-to-right and right-to-left override	U+202D, U+202E	Start an override
PDF: pop directional formatting	U+202C	End an embedding or override
LRI, RLI, FSI: left-to-right, right-to-left, and first-strong isolate	U+2066, U+2067, U+2068	Start an isolate
PDI: pop directional isolate	U+2069	End an isolate

Isolates arrived in Unicode 6.3, after embeddings proved to affect surrounding text too strongly, and the annex encourages them for new documents. Overrides are to be avoided wherever possible because of security concerns. On web pages, markup (HTML) and style sheets (CSS) should replace the embedding, override, and isolate characters; the dir attribute and the bdi element map to the isolates. The annex also says the formatting characters influence display only and have no effect on the comparison of text. The W3C article How to use Unicode controls for bidi text adds that they are invisible, although some editors can show symbols for them.

What breaks in extraction and search

Formatting characters carry state. UAX #9 warns that a process unaware of that state can change the rendering of large portions of text, for example by removing a single pop directional formatting character. When plain text is produced from a marked-up document, as in cut and paste, equivalent formatting characters should be inserted so the order is not lost.

Storage order is a second risk. Visual vs. logical ordering of text, a W3C article last substantively updated in 2013, describes Hebrew once stored in display order. A browser search, which captures text in logical order, then fails to match the stored text unless the browser has special logic for it. An ISO-8859-8 label indicates visual order, and ISO-8859-8-i indicates logical order.

Portable Document Format (PDF) files add a third. The PDF 1.7 standard, ISO 32000-1:2008, notes that many Arabic and Hebrew fonts follow Western glyph conventions. A file can therefore store right-to-left text as strings whose character codes run in reverse order, and a marked-content tag, ReversedChars, tells a reader so.

Data formats can drop direction entirely. The W3C draft Strings on the Web, published July 16, 2026, says formats such as JavaScript Object Notation (JSON) store text in strings without language or direction metadata. Guessing from the first strong character fails for an Arabic book title that begins with the Latin letters HTML. Inserting control characters changes the identity of the string, and strings may no longer compare as equal.

What to check

• Does text extraction return logical order, and does it honor the PDF ReversedChars tag?
• Does search ignore LRM, RLM, ALM, and the embedding and isolate characters when comparing strings?
• Is any legacy text stored in visual order, for example labeled ISO-8859-8 rather than ISO-8859-8-i?
• When strings leave the system as JSON or comma-separated values (CSV), is base direction carried as metadata or guessed from the first strong character?
• Does the viewer reveal override characters, U+202D and U+202E, which UAX #9 says to avoid for security reasons?
• Do numbers and Latin part numbers inside an Arabic or Hebrew line keep their intended order on screen and after copy and paste?

Azcuna's BABEL reads, translates, and searches foreign-language documents entirely on-device, with no cloud and no connection, and keeps every claim tied to the passage it came from.

Sources

1. 1Unicode Standard Annex #9: Unicode Bidirectional Algorithm, Revision 52 · The Unicode Consortium (Unicode 18.0.0, September 1, 2026)
2. 2Unicode Bidirectional Algorithm basics · W3C Internationalization (Richard Ishida)
3. 3How to use Unicode controls for bidi text · W3C Internationalization (Richard Ishida)
4. 4Visual vs. logical ordering of text · W3C Internationalization
5. 5Document management - Portable document format - Part 1: PDF 1.7 (PDF 32000-1:2008) · Adobe Systems, authorized copy of ISO 32000-1, first edition, July 1, 2008
6. 6Strings on the Web: Language and Direction Metadata · W3C Internationalization Working Group, First Public Working Draft, July 16, 2026

Where this shows up in our work

• BABEL, offline multilingual translation and search translates and searches foreign-language documents on-device, every fact tied to its source passage.