Cf — Format

Left-To-Right Mark U+200E

Left-to-Right Mark is an invisible directional mark that forces the surrounding text to be treated as left-to-right.

Survives trim() and NFKC unchanged

3 bytes in UTF-8 · Zero width · General Punctuation

Unicode properties

Codepoint
U+200E
General Category
Cf — Format
Unicode block
General Punctuation
White_Space
No
NFKC
Unchanged
Rendered width
Zero width
UTF-8 size
3 bytes
Collapses in HTML
No

Encodings and escapes

UTF-8
E2 80 8E
UTF-16
200E
HTML decimal
‎
HTML hex
‎
HTML named
‎
JavaScript
"\u200E"
Python
"\u200E"
CSS content
"\200E"

What it was designed for

Correcting display order when left-to-right and right-to-left text are mixed. Unicode assigns it to the General Punctuation block and to General Category Cf, which is Format.

In practice U+200E is fixes garbled ordering when Latin text sits inside Arabic or Hebrew.

Does U+200E work as invisible text?

Yes, in both name fields and message bodies. Left-To-Right Mark has the Unicode property White_Space=No, so trim() does not remove it and the regex class \s does not match it.

NFKC leaves it unchanged, so a platform that normalizes input before storing it keeps the exact codepoint you pasted. That combination — surviving both the trim and the normalization — is what makes a character dependable rather than occasionally lucky.

How it compares to the alternatives

Four properties decide which invisible character to use, and they separate these three cleanly. Left-To-Right Mark is shown against the plain space and against the character most often recommended for blank names.

Left-To-Right Mark compared with Space and Hangul Filler across the four decisive properties
PropertyU+200EU+0020U+3164
CategoryCfZsLo
Removed by trim()NoYesNo
NFKCstablestable→ U+1160
Rendered widthZero widthNarrowWide
UTF-8 bytes313
Works in a name fieldYesNoNo

Left-To-Right Mark matches the reference character on both decisive properties, which is why it works where a space fails.

How to type U+200E

To insert U+200E, copy it from the button above. Copying is the only method that behaves identically on every operating system and in every application.

Copy and paste

Use the copy button at the top of this page. Paste into the destination field directly. If the field rejects it, paste into a plain-text editor first and copy from there — rich-text editors and some mobile keyboards rewrite pasted content.

In code

Insert it by escape sequence rather than by pasting a character no reviewer can see. A literal invisible character in a source file is unreadable in review and survives copy-paste into places it was never meant to reach.

  • JavaScript and TypeScript — "\u200E"
  • Python — "\u200E"
  • HTML — ‎ or ‎ or ‎
  • CSS content"\200E"
  • URL encoding — %E2%80%8E

Keyboard entry

Keyboard methods exist and none is reliable across systems. On Linux and in most GTK applications, Ctrl+Shift+U followed by 200e and Enter inserts the character. On macOS, the Unicode Hex Input source acceptsOption plus the four hex digits, and it must be enabled in Keyboard settings first.

Windows Alt codes do not cover this range. The Alt plus numeric-keypad method addresses legacy code pages rather than Unicode codepoints, so it cannot produce U+200E. Copying remains the dependable method on every platform.

How many fit in a field

As many as the field's limit allows, because each one counts as a full character. An invisible character is not free — it consumes the same budget as a letter.

It costs 3 bytes in UTF-8, against 1 byte for a plain space. Fields enforce either a character limit or a byte limit, and the two give very different answers. A 20-character gamertag holds 20 of them. A 20-byte field holds 6.

Platforms rarely state which limit they enforce. A field that accepts 20 letters and rejects 20 invisible characters is counting bytes, so divide the stated limit by 3 to find the real ceiling.

Why U+200E fails, and what to do

It fails when a field measures rendered width rather than string length, because this character draws nothing. Everything else about the character is stable, so a failure almost always traces to that one condition.

The field clears itself after saving. The value was trimmed to an empty string and the platform restored the previous one. Move to a character withWhite_Space=No, which this one already has.

A box or question mark appears. The font has no glyph at U+200E, so the renderer drew .notdef. The stored value is correct and only the display is wrong. U+2800 has the widest font coverage of the invisible characters.

The value changes between saving and reloading. The platform normalized it. NFKC leaves Left-To-Right Mark unchanged, so the cause is a platform-specific substitution rather than normalization.

It works on desktop and fails in a mobile app. The two clients validate separately, and some mobile keyboards strip invisible characters on paste. Paste into a plain-text notes app first, then copy from there.

Is it a security risk?

Yes, in source code and identifiers, and no in ordinary text. U+200E changes the display order of surrounding text without changing the stored bytes, so rendered text can differ from what a program reads. This is the Trojan Source class of issue, disclosed in 2021.

The exposure is limited to contexts where an invisible character changes meaning without changing appearance. Pasting U+200E into a username, a bio or a chat message creates no such risk, because nothing downstream interprets it.

To audit text you did not write, match the category with\p{Cf} rather than searching for this codepoint alone.

Where it is used

It is used wherever a field must not be empty but should look empty. Platform behaviour differs enough that each category has its own guide.

How to find it in existing text

Match it by category rather than by codepoint. The regex\p{Cf} matches Left-To-Right Mark and every other character in its category, and it keeps working across Unicode releases.

To confirm whether a specific string contains it, paste the string into the invisible text detector, which lists every codepoint with its category and byte length.

Other Format characters

Every character below shares categoryCf, so all of them behave identically undertrim(). Only their width and byte cost differ.

See all 29 invisible characters

Frequently asked questions

01

What is U+200E?

U+200E is Left-To-Right Mark. Left-to-Right Mark is an invisible directional mark that forces the surrounding text to be treated as left-to-right.

02

Does Left-To-Right Mark work in a username?

Yes. Left-To-Right Mark has White_Space=No, so trim() does not remove it and the regex class \s does not match it. NFKC leaves it unchanged, so the value a platform stores matches the value you pasted.

03

How do I type U+200E?

Copy it from the button on this page. To insert it in code, use the escape sequence \u200E in JavaScript or Python, or the HTML entity ‎. On Windows, Alt codes do not reliably produce invisible characters, so copying is the dependable method.

04

How many bytes does Left-To-Right Mark use?

3 bytes in UTF-8. A field that enforces a byte limit rather than a character limit counts it as 3, so a 30-byte field holds 10 of them.

05

Where can I copy and paste Left-To-Right Mark?

Use the copy button at the top of this page. Left-To-Right Mark copy paste puts the single codepoint U+200E on your clipboard with nothing attached — no leading space, no trailing newline.

06

What is the code for Left-To-Right Mark?

The codepoint is U+200E, written as unicode 200E in short form. In HTML it is ‎ or ‎, and in JavaScript or Python it is the escape \u200E.

07

Why does Left-To-Right Mark show as a box?

The font in use has no glyph for that codepoint, so the renderer draws the .notdef glyph, which most fonts display as an empty rectangle. The character is stored correctly and only the display is wrong.

Written by , developer and writer.

Last reviewed