Invisible character

Copying a blank that actually survives the paste

Copying a space out of a text field and pasting it into a name or a caption almost never works, because the space is trimmed at the other end. These characters are not spaces, which is why they get through.

1. 1Pick the character from the list. Each one shows its Unicode code point so you can look up its support before relying on it.
2. 2Press copy. A blank is written to your clipboard, so the button confirming the copy is the only feedback there is: there is nothing to see.
3. 3Paste it where you need it and check the result before saving. Support varies by field, not just by platform, and a bio may accept what a display name rejects.
4. 4If it comes out as an empty box, the font has no glyph for it. Try the non-breaking space instead, which every font can draw.
5. 5For spacing a caption into paragraphs, use the line break generator rather than pasting these by hand: it inserts the right character on every blank line for you.

The characters on offer and where each one holds up

They are not interchangeable. Some have width and some have none, and that difference decides whether a platform treats the line as empty and discards it.

• Braille blank, U+2800. Has real width, so a composer sees a line with content and keeps it. The most reliable choice for caption spacing, and screen readers skip it.
• Hangul filler, U+3164. Wide and blank, and accepted as a name character in fields that reject a plain space, which is why it turns up in game handles.
• Zero-width space, U+200B. No width at all. Good for breaking a long word without a visible gap, and the one most often stripped by sanitisers for exactly that reason.
• Word joiner, U+2060. Zero width and prevents a line break at that point. Survives more sanitisers than the zero-width space does.
• Non-breaking space, U+00A0. A visible space that never collapses or wraps, and the safe fallback when a client draws the braille blank as a box.
• Figure space, U+2007. As wide as a digit and non-breaking, designed for aligning numbers in a column rather than for padding a caption.

Why platforms keep removing them

Invisible characters are not a loophole nobody noticed. Platforms strip them on purpose, and knowing what the stripping is for tells you which uses are safe and which are a waste of effort.

• They defeat text search. A word with a zero-width space inside it does not match a search for that word, which is the oldest trick for evading a moderation filter.
• They enable impersonation. Two usernames that look identical but differ by an invisible character are a phishing primitive, so identity fields are sanitised hardest.
• They break sorting and deduplication. A support system sees two different strings where a human sees one name.
• Accessibility is the honest concern. A screen reader may announce some of these, which is why the braille blank is the default here: it is the one that is reliably skipped.
• The result is that display names and usernames strip aggressively, captions and bios are more permissive, and none of it is documented or stable.

The honest limits of this trick

This page exists because the technique works often enough to be useful, not because it always works. Being straight about that saves you from debugging a platform decision as if it were a bug in the text.

• Nothing here is guaranteed anywhere. A field that accepts one of these today can silently start trimming it after any deployment, with no announcement.
• They are real characters and count against character limits, so a caption padded with them has less room for words.
• An empty message made only of invisible characters is treated as spam by several platforms and may be rejected or shadow-limited.
• They are not a way to hide text from moderation, and attempting it is what causes the stripping to get more aggressive for everyone else.
• If your only goal is paragraph spacing in a caption, that is a solved problem with its own tool, and doing it by hand tends to leave inconsistent gaps.