Which character iMessage accepts
iMessage accepts U+2800. Because iMessage does not trim the body the way most clients do, a plain space sends. An invisible character is still the better choice — a space can be stripped downstream, and it fails as soon as the thread falls back to SMS.
The fallback is U+200B, which clears validators the first character does not. Both survive trim(), which is the operation that destroys an ordinary space.
The field caps at 20000 characters, and every invisible character counts as one. A name of 20000 invisible characters is the maximum iMessage will store.
How to set it on iMessage
To set blank text on iMessage, copy the character above and paste it into a cleared field. The whole method is one paste — the cost is free over iMessage; SMS is charged per segment on metered plans.
- Copy U+2800 from the tool above.
- Open Messages and tap the text field.
- Paste the character.
- Tap the send arrow.
On Android
Copy the character, open iMessage, clear the field and long-press to paste. If the paste produces nothing, the keyboard's clipboard manager stripped it — copy from the browser directly rather than from a clipboard history panel.
On iPhone and iPad
iOS sanitises some pasted content between apps. Paste the character into Notes first, select it there, copy again, then paste into iMessage. The second copy comes from a plain-text source and survives.
On desktop and emulators
Desktop clients paste the character unmodified, so the browser-to-app route works directly. Android emulators such as BlueStacks and LDPlayer share the host clipboard, and pasting into the emulator's own notes app first avoids the same stripping that affects physical devices.
Why an invisible character works where a space does not
One Unicode property decides it, and it is not the one most guides name. Every character carries a White_Space value of Yes or No, and that value determines whether trim() removes it.
The spacebar produces U+0020, whose White_Space value is Yes. iMessagetrims the field before saving, the trimmed value is empty, and the field falls back to its previous contents. That is why a name built from spaces looks correct in the editor and reverts the moment you save.
U+2800 has White_Space=No. No trimming function removes it and the regex class \s does not match it, so the value that reaches the server is the value you pasted.
One caveat applies to U+3164 specifically. Normalization Form NFKC folds it to U+1160 Hangul Jungseong Filler, so a platform that normalizes before storing keeps a different codepoint than the one you pasted. The name still displays blank. Use U+1160 directly if you want the stored value to match exactly.
What it costs on iMessage
Free over iMessage; SMS is charged per segment on metered plans. Nothing is consumed by a failed attempt, so trying a second character costs only the time.
If it does not work on iMessage
A green bubble means the message went as SMS. An invisible character forces UCS-2 encoding there, cutting the per-segment limit from 160 characters to 70.
The field clears itself after saving
iMessage trimmed the value and found an empty string, so it restored the previous one. The character you used has White_Space=Yes. Switch to U+2800 or U+200B, which do not, and the value survives the trim.
A box or question mark appears
The rendering font has no glyph at that codepoint, so the renderer draws.notdef — an empty rectangle in most fonts. The stored value is correct and only the display is wrong. U+200B carries wider font coverage than most alternatives.
The paste produces nothing on mobile
The keyboard or clipboard manager sanitised the content in transit. Paste into a plain-text notes app first, copy from there, then paste into iMessage. This is the single most common practical failure and it has nothing to do with the character itself.
It works on desktop and fails in the app
The two clients validate separately. A value the desktop site accepts can still be rejected by the mobile client's own check, and the reverse also happens. Set it on whichever client accepts it — the stored value is shared.
Full property data for both characters is on the Unicode invisible characters table.
Is a blank name allowed on iMessage?
Yes. A blank name breaks no iMessage rule. Platform policies restrict impersonation, harassment and filter evasion, not which codepoints a name contains.
Two uses do violate policy on iMessage and on every comparable platform, and neither depends on the name being blank. Copying another user's name to pass as them is impersonation. Splitting a blocked word with a zero-width character to defeat moderation is evasion.
One consideration applies regardless of the rules. Screen readers announce nothing for an invisible character, so NVDA, JAWS and VoiceOver read a fully blank name as unnamed. Keeping one visible character alongside the invisible ones preserves the announcement and still looks almost blank.