Text direction for mixed Hebrew and English

A file gets dir="rtl" because it is "a Hebrew document", and every English paragraph in it inherits that. The words stay in order — bidi handles those — but the paragraph aligns to the right and its full stop moves to the left of the sentence.

The same happens in reverse: one Hebrew line inside an English document ends up left-aligned with its final period stranded on the right. Neither is a rendering bug. The browser was told the direction and believed it.

dir="auto" reads forward through the paragraph until it meets a character with a direction of its own, and takes that direction. Most characters have none, which is the part that surprises people: a paragraph can open with a number, a quotation mark and a space and still resolve from a letter much further in.

• Digits never decide. 2026 was a good year resolves from w, and 2026 היה שנה טובה resolves from ה. Both are correct, and neither is affected by the year in front.
• Nor does punctuation. An opening quotation mark, a bullet, or a bracket is neutral. The paragraph resolves from the first letter after it.
• Emoji are neutral too. A line that is only emoji has nothing to resolve from at all — see below.

A paragraph made only of digits, punctuation or emoji has no strong character, so there is nothing for the first-strong rule to read. The empty paragraph you get from pressing Enter is the same case.

The specification has an answer for this and it is usually the wrong one for a document: dir="auto" falls back to the direction of the parent element. In a mixed document the parent is whatever the file was opened as, so an empty line in the middle of a Hebrew passage jumps to left-to-right, the caret lands on the wrong side, and the writer has to fight it back. Nothing is broken — the rule simply has no better information.

• The fallback that behaves the way a writer expects is the direction of the paragraph above, not the direction of the file. A new line continues the passage it was created inside.
• HTML cannot express that. dir="auto" is per-element and knows nothing about the element before it, so an editor that wants this behaviour has to compute direction itself.
• At the very top of a document there is no paragraph above either. The only sensible fallback left is the direction of the interface language.

Direction resolves per paragraph, but a paragraph can still contain a run of the other direction, and the neutral characters between the two runs have to attach to one of them. Almost always they attach correctly. When they don't, an invisible mark forces it.

• Reach for an isolate before a mark when you are inserting text of unknown direction into a sentence. It is what the isolates were added for.
• The older embedding controls U+202A–U+202E still work and are best avoided: they have no scope, so a missing terminator corrupts the rest of the paragraph.
• These characters are invisible and they are real. They survive copy and paste, count toward a length limit, and will not match a naive string comparison.

Right-to-left is not only Hebrew and Arabic. A first-strong implementation has to recognise all of these, or a document in one of them resolves the wrong way with no visible reason.

• The algorithm is Unicode Standard Annex #9, the Unicode Bidirectional Algorithm. The first-strong rule is clauses P2 and P3; the character classes are the Bidi_Class property in the Unicode Character Database.
• dir="auto" is defined in the HTML Living Standard, which delegates to the same rule.
• Script blocks checked against the Unicode Character Database on 31 August 2026.

Found something out of date or wrong? Tell us and it gets fixed — a reference nobody corrects stops being one.