What it was designed for
French typography, where it precedes punctuation such as the colon and semicolon. Unicode assigns it to the General Punctuation block and to General Category Zs, which is Space Separator.
In practice U+202F is the standard space before French punctuation.
Does U+202F work as invisible text?
No — it is removed by trim(). ItsWhite_Space property is Yes, so every standard trimming function strips it and the regex class \s matches it.
A name field that rejects an empty value rejects this character, because after trimming there is nothing left. Use U+3164 Hangul Filler or U+2800 Braille Pattern Blank instead, both of which survive.
Narrow No-Break Space remains the correct choice for typographic spacing, where the goal is a measured gap in rendered text rather than a value that survives validation.
How it compares to the alternatives
Four properties decide which invisible character to use, and they separate these three cleanly. Narrow No-Break Space is shown against the plain space and against the character most often recommended for blank names.
| Property | U+202F | U+0020 | U+3164 |
|---|---|---|---|
| Category | Zs | Zs | Lo |
| Removed by trim() | Yes | Yes | No |
| NFKC | → U+0020 | stable | → U+1160 |
| Rendered width | Narrow | Narrow | Wide |
| UTF-8 bytes | 3 | 1 | 3 |
| Works in a name field | No | No | No |
Narrow No-Break Space behaves like the plain space on the two properties that matter, which is why it fails wherever a space fails.
How to type U+202F
To insert U+202F, 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 —
"\u202F" - Python —
"\u202F" - HTML —
 or  - CSS
content—"\202F" - URL encoding —
%E2%80%AF
Keyboard entry
Keyboard methods exist and none is reliable across systems. On Linux and in most GTK applications, Ctrl+Shift+U followed by 202f 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+202F. Copying remains the dependable method on every platform.
Why U+202F fails, and what to do
It fails when a field trims its input, which every name field and message composer does. 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 — U+3164 or U+2800.
A box or question mark appears. The font has no glyph at U+202F, 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. Narrow No-Break Space folds to U+0020 under NFKC, so that is the codepoint now stored.
How to find it in existing text
Match it by category rather than by codepoint. The regex\p{Zs} matches Narrow No-Break Space 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.