Why does Hebrew display in the wrong order in English text?

The Unicode Bidirectional Algorithm guesses direction from surrounding context. In a left-to-right paragraph, an embedded Hebrew run plus adjacent numbers or punctuation can be reordered incorrectly. Explicit bidi control characters tell the renderer exactly where the right-to-left run starts and ends.

What is the difference between isolates and embeddings?

Isolates (RLI U+2067 to PDI U+2069) are the modern recommendation: they set direction without letting the run affect the ordering of text around it. Embeddings (RLE U+202B to PDF U+202C) are the older mechanism and can have side effects on neighbouring characters, so prefer isolates unless you need legacy support.

When should I use the RLM marks option?

Right-to-Left Marks (U+200F) are a lightweight fix that nudges direction at a single point without wrapping a whole run. They are useful in places where you cannot insert paired controls, such as some plain-text fields, though they are less robust than isolates for longer runs.

The output looks identical to the input. Did it work?

Yes. Bidi control characters are invisible by design, so the copied text looks the same but carries hidden markers. Use the escaped view to confirm the markers are present; it shows each control character as its \uXXXX code so you can verify placement.

Is my text processed locally?

Yes. The marker insertion runs entirely in your browser. No text is uploaded, so your content stays private on your device.

What is the Hebrew RTL Direction Fixer?

Wrap Hebrew runs in mixed Hebrew-English text with the correct Unicode bidi control characters (RLI/PDI isolates, RLE/PDF embeddings, or RLM marks) so they display in the right order inside LTR HTML, code, and documents. Free and private. It runs free in your browser on Gera Tools, with nothing uploaded.

Hebrew RTL Direction Fixer

Name: Hebrew RTL Direction Fixer
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

This tool fixes the garbled ordering you get when Hebrew is embedded inside left-to-right text, by inserting the correct invisible Unicode bidi control characters around each right-to-left run.

How it works

The tool scans for maximal runs of strong right-to-left characters (Hebrew, Arabic, and their presentation forms) and bridges any neutral characters — spaces, digits, punctuation — that sit between two RTL letters so a run like שלום 2 עולם stays intact. It then wraps each run using your chosen strategy:

isolate:  RLI (U+2067) … run … PDI (U+2069)
embed:    RLE (U+202B) … run … PDF (U+202C)
mark:     RLM (U+200F) … run … RLM (U+200F)

Isolates are the modern Unicode recommendation because they contain the run’s direction without disturbing the surrounding text. The escaped output renders each inserted control character as a visible \uXXXX escape so you can confirm exactly what was added.

Example

Take the sentence The sign reads שלום 18 today. In a left-to-right context the number 18 next to the Hebrew can be reordered awkwardly. After fixing, the Hebrew run plus its bridged digits are isolated, so the phrase renders in the intended order while the English around it is untouched.

Understanding the Unicode Bidirectional Algorithm

The Unicode Bidirectional Algorithm (UBA) is what every text renderer uses to determine the visual order of characters. It works by classifying each character as having a strong direction (left-to-right like Latin letters, or right-to-left like Hebrew and Arabic), a weak direction (numbers and currency symbols), or neutral (spaces and punctuation).

The algorithm then applies a set of rules to resolve the display order for each paragraph, using the paragraph’s base direction and the embedding level of any bidi controls. For most pure-Hebrew or pure-English text this works automatically. Problems arise at boundaries:

A Hebrew phrase next to a number: the number is neutral or weak and can be pulled into the surrounding LTR context, placing it to the wrong side of the Hebrew text.
Punctuation at the edge of a Hebrew run: a period or comma at the end of a Hebrew phrase can jump to an unexpected position because punctuation is directionally neutral.
Multiple RTL and LTR runs in a single paragraph: the algorithm resolves ambiguous runs relative to the outermost paragraph direction, which may not match your intent.

Explicit bidi controls override the algorithm’s automatic inference and tell the renderer exactly where an RTL run begins and ends.

Choosing the right strategy

Isolates (RLI/PDI) are the right default. They isolate the RTL run so it cannot influence the ordering of text around it. This matches how you think about the problem: “this Hebrew phrase should be treated as a unit, self-contained, inside the surrounding LTR sentence.”

Embeddings (RLE/PDF) are the older mechanism and work on all systems, but they have a subtle flaw: the RTL run is not isolated from the outside context, so characters at the boundary can still be affected by the direction rules of the surrounding text. Use embeddings only when targeting systems that predate Unicode 6.3.

RLM marks are single invisible right-to-left marks that nudge direction at a specific point without wrapping a run. They are useful in contexts where control characters may be filtered out (some database fields, some CMS systems), as a lightweight fallback. They are less precise than isolates for long runs or runs containing neutral characters.

Notes

Because the markers are invisible, paste the fixed text where it will be displayed and use the escaped view only to verify placement. Prefer isolates for HTML and modern editors; reach for RLM marks only in constrained plain-text fields that strip paired controls.