What an invisible character actually is
An invisible character is not a missing character and it is not an ordinary space. It is a real Unicode codepoint that a font draws as nothing, or draws as a blank box with no marks in it. Your keyboard has one blank key and it produces U+0020, the space every piece of software on earth knows how to collapse, trim and reject. The characters on this page are the ones it does not know what to do with.
That difference is the entire reason this tool exists. If you have ever tried to leave an Instagram bio line empty, set a Discord nickname that looks like nothing, or push a caption down the screen with blank lines, you have run into a field that quietly deleted your spaces the moment you pressed save. It was not a bug. Almost every text field on the internet runs your input through a trim step first, and that step is written to remove exactly the character your space bar produces.
Why some blanks survive and others vanish
Unicode sorts every character into a General Category, a two-letter code that says what kind of thing it is. That code is boring metadata until you realise it is what decides whether your blank makes it through. Four categories matter here.
- Zs, Space Separator. Real whitespace. The no-break space and the ideographic space live here. They have width and they look right, but any field that says "this cannot be blank" is checking for exactly this category, so they fail the same validation an ordinary space fails.
- Cf, Format. Invisible instructions rather than content: zero width space, word joiner, the zero-width joiner that holds emoji sequences together. They take up no room at all, which makes them ideal, and they are the category most aggressively stripped on save, which makes them unreliable.
- Lo, Letter. The Hangul Filler is here. Unicode considers it a letter, in the same sense that A and क are letters. A username field demanding letters looks at it and sees a letter, even though the glyph is empty.
- So, Symbol. The braille pattern blank is a braille cell with none of its dots raised. It is a visible symbol whose picture happens to be empty, so nothing treats it as whitespace and nothing trims it.
Read that list again and the whole problem reorganises itself. You are not looking for the most invisible character. You are looking for the one whose category matches the check that is standing between you and the thing you want. A field rejecting empty input needs a letter or a symbol. A field collapsing repeated spaces needs something outside Zs. A field that strips formatting needs something outside Cf.
You are not looking for the most invisible character. You are looking for the one whose category gets past the check in front of you.
Usernames, bios and messages are three different problems
People searching for this rarely have one need, and the three common ones fail for different reasons. It is worth knowing which one you have before you start pasting.
A username or display name is the strictest. It is usually unique across the whole service, it is often part of a URL, and it is validated hard: a minimum length, a rule about what counts as a real character, sometimes a ban on leading and trailing blanks. This is where the letter and symbol categories earn their place, because they satisfy a length check and a has-real-characters check at the same time.
A bio or a status is looser. The usual failure here is not rejection but collapse: you type three blank lines to space out your text, save, and the app folds them into one. Putting a non-space character on each otherwise-empty line gives the line something to hold, so it survives the fold.
A message is the easiest case and the one most likely to backfire. Chat apps rarely strip anything, so almost any of these works. But the person on the other end may be reading with a screen reader, or copying your text somewhere else, and invisible characters are genuinely disruptive in both situations. Use them for a bio flourish. Do not use them in something a person needs to read or act on.
When it looks broken
Two failures come up constantly, and both look like the tool is at fault when it is not.
The first is a small rectangle where your blank should be, sometimes with tiny numbers inside it. That is tofu, the placeholder a font draws when it has no glyph for a character. The character arrived intact; the font on that particular device simply does not cover it. The braille blank and the Hangul Filler have the widest font coverage of anything on this page, so switching to one of those usually clears it.
The second is the disappearing act: it works, you save, you reload, and the gap is gone. The field stripped it server-side. Nothing you do in the browser changes that, and no tool anywhere can force it, whatever the pages claiming universal support tell you. Move up the category list — try the Hangul Filler, then the braille blank — and if neither survives, that field genuinely will not hold a blank.
Which brings up the one thing worth saying plainly. Support changes without notice, because the people writing these validators are trying to stop spam and impersonation, not trying to stop you. Any page that hands you a confident table of which app accepts what is telling you how things were on the day it was written. The reliable move is the one built into the tool above: paste it, save it, reload, and look.