Blank Character Comparison Hub
Compare 24 blank-looking, invisible, whitespace, and separator Unicode characters — Hangul Filler, Zero Width Space, Braille Blank, and more — with general platform notes for Discord, Instagram, WhatsApp, TikTok, and other apps. Support varies by field and account, so always test before relying on one. Need the fast copy-and-go tool instead? Use the blank character generator.
Full character catalog
24 invisible, blank-looking, and spacing characters, each with its Unicode code point and behavior notes. The category labels below (Zero-Width, Blank-Looking, Whitespace Variant, Separator) are our own groupings for readability, not official Unicode category names.
Platform support matrix
Rough, character-level notes based on our own testing and each platform's current published rules (reviewed August 2026) — not live validation. Compatibility can differ by field (username vs. bio vs. message), account type, and app version, and platforms update their rules often, so treat this as a starting point and test before relying on it for anything important.
Note: usernames on most of these platforms are restricted to a fixed character set (letters, numbers, and a few symbols), so most rows below are rejected for username fields specifically even where they're marked field-dependent overall — see each platform's guide for the exact rule.
Zero-width vs blank-looking vs whitespace: what's the difference
These three terms get used interchangeably, but they describe different behavior at the Unicode level, and those differences can affect how applications handle each character — though the application's own validation rules, not just the Unicode category, ultimately decide what's accepted.
Zero-width characters
These characters normally have no visible glyph or advance width in ordinary text rendering. They exist mainly for text-shaping purposes: joining or separating script glyphs (like Zero Width Joiner in emoji sequences), or marking word/line boundaries for layout engines. Because they render as nothing, they're often stripped by input fields that trim "empty-looking" content — but this depends on the specific field's validation, not a universal rule.
Blank-looking characters
These may render as an empty-looking glyph or placeholder, but they aren't a single uniform group — their actual width, Unicode category, and rendering depend on the specific character, font, and text engine. For example, the Hangul Filler (U+3164) is a Letter with no visible glyph in normal rendering, while the Braille Pattern Blank (U+2800) is a Symbol that can render as a fixed-width blank but isn't a space. Because many validators only strip characters they recognize as whitespace, these can sometimes get through — but that's field- and platform-specific, not guaranteed.
Whitespace variants
These are true space characters with visible width, just not the standard U+0020 space — en space, em space, thin space, ideographic space, and similar. They are Unicode whitespace characters and are commonly treated as spacing characters by text-processing systems, so they get collapsed or trimmed at the start/end of fields more often than blank-looking characters, but they're generally more predictable for controlling spacing width inside a line of text.
Technical deep dive
How input validation usually works
Many applications normalize or sanitize user input before saving it — using a trim()-style whitespace strip, a regex, a code-point allowlist, or a custom sanitizer — and the exact rules vary by platform and by field. Some applications remove zero-width or whitespace characters during validation, while others preserve them. Blank-looking characters such as the Hangul Filler or Braille Pattern Blank aren't always caught by whitespace-focused filters, since they aren't classified as whitespace by Unicode, but plenty of platforms reject them anyway through character-set allowlists — this is not a reliable way to guarantee a character survives.
Normalization and encoding
Some applications normalize Unicode text before storing or comparing it. Compatibility normalization such as NFKC can change certain compatibility characters (for example, mapping a halfwidth or compatibility form to its canonical equivalent), while separate validation or sanitization steps may remove format characters. Which characters are affected depends on the specific normalization form and the platform's own rules — it's not limited to any one group of characters.
Line Separator and Paragraph Separator
U+2028 and U+2029 are Unicode line and paragraph separator characters. Single-line input fields (usernames, display names) commonly reject, normalize, or strip them because they represent line or paragraph boundaries. Multi-line fields (messages, documents, bios) are more likely to honor them, sometimes rendering an actual line break instead of a blank character — but this varies by app and hasn't been verified for every platform listed here.
Why identical-looking characters behave differently
Several characters in this catalog render identically — blank — in most fonts, but belong to different Unicode categories (Zs for space separators, Cf for formatting characters, So for symbols, and some default-ignorable Letters like the Hangul Filler). Platforms may use Unicode categories, code-point allowlists, normalization, or entirely custom validation rules to decide what to accept, which is why two characters that look the same can behave very differently on the same platform.
Which one should you use
Pick your use case for general guidance. For usernames especially, always check the specific platform's rules — this is not a universal recommendation.
Username
Username validation is platform-specific, not universal — many platforms (Discord, TikTok, X, Instagram, Roblox among them) currently restrict usernames to a fixed character set of letters, numbers, and a few symbols, which rules out invisible or blank-looking characters entirely. Check the specific platform's current username rules before picking a character; there's no single character that works as a username everywhere.
Bio
Bio fields may allow more Unicode characters than usernames since they're typically free-text, but support still varies by platform and field — some strip zero-width characters, others strip blank-looking ones, and some accept both. Test the character on the specific platform first.
Message
Chat apps handle whitespace and blank-looking characters differently from each other, and behavior can change with app updates. Test the character in the specific app before relying on it, rather than assuming a message field will preserve it.
Formatting / spacing control
For controlling visible gap width inside a line — for example aligning text — a whitespace variant with a defined width is more predictable than a zero-width or blank-looking character.
File names
File-name handling for invisible and blank-looking characters depends on the operating system, file system, and any sync service involved (iCloud, OneDrive, Google Drive, etc.), so there isn't one character that behaves consistently everywhere. If you need a workaround, test on your specific OS and sync setup first rather than assuming compatibility.
Programming / code
Avoid invisible characters in source code entirely where possible — they cause hard-to-debug errors and some linters/CI systems will flag or reject them. If you're intentionally testing how your code handles invisible characters (for example, input sanitization), use a well-known code point such as U+200B or U+2060 and document exactly what you're testing, rather than relying on any one character being "recognized" by tooling in general.
Examples
Blank-looking line in a bio
Example: inserting a Braille Pattern Blank on its own line between sections of a bio. If the platform accepts U+2800, it may render as a blank-looking line — but not every platform preserves blank lines or this character, so test it on the app you're using first.
Invisible name prefix for sorting
Some applications may sort strings containing a Hangul Filler differently from ordinary visible text — for example, ahead of visible letters in a list. Sorting behavior depends on the app's collation rules and isn't guaranteed.
Custom-width gap between words
Using a thin space instead of a regular space gives a tighter, more deliberate gap — useful in display names or headings where the platform preserves the character.