Bidirectional overrides
RIGHT-TO-LEFT EMBEDDING (U+202B)
Opens a right-to-left run inside surrounding text, until a matching POP DIRECTIONAL FORMATTING closes it.
- Codepoint
U+202B- Category
- Bidirectional overrides
- Removed by default
- Yes
- Governing option
- No option needed
- Can be load-bearing
- No
Where it comes from
Legacy Hebrew and Arabic document workflows, and text copied out of them.
Why it matters
Like its left-to-right twin it nests, leaks past the end of the intended span when unterminated, and is completely invisible while doing it.
Before and after
The Hebrew word reads right to left on its own. The embedding around it adds nothing but risk.
The character is shown as a labelled chip so you can see where it sits. In your text it draws nothing at all.
When it is legitimate
Superseded by U+2067 RIGHT-TO-LEFT ISOLATE, which cannot leak. Genuine Hebrew and Arabic prose needs no embedding at all — the bidi algorithm reads the direction from the letters.
How to remove it
The default pass removes it, unconditionally.
Is it an AI watermark?
Not a watermark
No. A legacy layout control from bidi-aware editors. Nothing to do with generated text.
No connection to machine-generated text. It comes from software, from a keyboard, or from a person.
Questions
Will removing it break my Hebrew?
No. Hebrew and Arabic letters carry their own directionality, so the bidi algorithm lays them out correctly with no control characters present.
What about the marks next to the text?
U+200E and U+200F are treated differently: next to right-to-left text they are kept, because there they resolve genuine ambiguity.
Check your own text
Paste anything into the cleaner to see every hidden character it contains, with position, codepoint and what happens to each one. Nothing is uploaded.