Gera Tools

Persian RTL Direction Fixer

Fix bidi rendering for Persian text pasted into LTR environments

Fix mangled bidirectional rendering of Persian text in left-to-right environments by wrapping it in Unicode direction controls (RLI/PDI, RLE/PDF, or RLM). Strips existing controls first so wrapping is idempotent. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

Why does Persian text render in the wrong order?

When right-to-left text sits in a left-to-right host such as a code comment or a CSV cell, the bidirectional algorithm can reorder punctuation, numbers, and embedded Latin incorrectly. Direction controls tell the host to display the run right-to-left.

Fix Persian text that renders backwards

Persian is right-to-left, but many editors, spreadsheets, and chat boxes default to left-to-right. Pasting Farsi there can scramble the order of punctuation, numbers, and embedded Latin. This tool wraps your text in Unicode bidirectional controls so it renders correctly anywhere.

How it works

The fixer first removes any existing bidi format characters, then wraps the clean text in the controls for the method you pick:

  • RLI…PDI (U+2067…U+2069) — Right-to-Left Isolate. The modern, recommended approach; it isolates the run so it does not disturb neighbouring text.
  • RLE…PDF (U+202B…U+202C) — Right-to-Left Embedding. A legacy embedding with the widest compatibility.
  • RLM (U+200F) — a Right-to-Left Mark prefix, the lightest hint when a full wrapper is overkill.

Because existing controls are stripped first, the operation is idempotent — running it again will not pile up extra characters.

Understanding the bidi problem in detail

The Unicode Bidirectional Algorithm (UBA) determines text direction by looking at the surrounding context and the strong directionality of the characters. In an overwhelmingly LTR context — a code editor, a CSV cell, an HTML attribute — the algorithm often assigns the run to left-to-right even when the first strongly directional character is RTL. The result is that:

  • Punctuation (parentheses, colons, slashes) appears on the wrong side
  • Numbers, which are weakly directional, anchor to the LTR flow instead of sitting naturally within the RTL run
  • Mixed strings like (قیمت: 100) can have the parentheses entirely flipped

The controls this tool adds are invisible characters that explicitly tell the UBA what to do, overriding the context-inference step.

Which method to choose

RLI…PDI is the right choice for almost all modern use. It creates an isolated bidirectional scope so the RTL run cannot bleed into adjacent LTR text and vice versa. Use it in HTML pages, modern apps, and any environment that follows the Unicode 6.3+ spec.

RLE…PDF is the older approach and still has broader compatibility in legacy systems and older email clients. It embeds rather than isolates, meaning the surrounding text can affect and be affected by the embedding — less predictable, but sometimes necessary.

RLM prefix is the lightest touch: a single invisible mark at the start of the string that nudges the UBA toward RTL. It works well for short, purely RTL strings with no embedded Latin or numbers.

Example and notes

A string like قیمت: 1500 تومان (Persian) often shows the number and parentheses in the wrong place inside an LTR field. Wrapping it with RLI…PDI keeps the whole run right-to-left while leaving the visible characters untouched. The tool reports how many invisible control characters were added so you know the wrapper is present.

If you are debugging rendering in a browser, open DevTools and inspect the raw text content of the element to confirm the control characters are present — they are invisible in the rendered view.

All processing is local — your text never leaves the browser.