Why fancy text shows up as boxes, question marks or blank squares
Short answer: the characters arrived fine — the other person’s device has no glyph to draw them. A box (□), a question mark, or a blank rectangle is the font saying “I received a valid character I don’t have a picture for.”
This is not a copy-paste failure. The text is intact. If they copied it and pasted it somewhere with a better font, it would render correctly.
Where the failure happens
Text goes through four stages, and only the last one breaks:
- The generator maps your letters to Unicode code points — deterministic, no rendering involved
- The platform stores and transmits them — it does not care what they look like
- The other device receives the exact same code points you sent
- The font on that device tries to find a glyph for each one — and may not have it
Stage 4 is entirely outside anyone’s control but the device owner’s. No generator can fix it, and any tool claiming its characters “work everywhere” is overselling.
Which situations actually break
Older Android. Font coverage has expanded a lot over the years. Older system fonts simply do not include the more obscure blocks, and there is no fallback to find.
Windows + Chrome, historically. This combination has a long track record of showing empty boxes for mathematical alphanumerics while the same page renders fine on macOS and Linux. It is a font-fallback chain issue, not a browser bug in the usual sense.
Games with custom fonts. Minecraft is the common case: a resource pack that replaces the default font usually covers ASCII and little else. Your server menu looks right in a vanilla client and turns into boxes for everyone using the pack. See small caps for Minecraft servers for the specifics.
Anywhere the app ships its own font rather than using the system one — some chat clients, some embedded webviews, some TV and console interfaces.
Which styles are safest
Not all decorative styles carry the same risk. The rough ordering, safest first:
| Style | Risk |
|---|---|
| Small caps (ꜱᴍᴀʟʟ ᴄᴀᴘꜱ) | Low |
| Superscript (ˢᵘᵖᵉʳ) | Low |
| Circled (ⓒⓘⓡ), full-width (Ｆｕｌｌ) | Low–medium |
| Math bold / italic / script / fraktur | Medium–high |
| Combining marks (s̶t̶r̶i̶k̶e̶, z̸a̸l̸g̸o̸) | Varies |
The reasoning behind that ordering:
- Small caps is mostly IPA characters, which are present in any font supporting phonetic notation — that is most system fonts.
- Superscript comes from a long-established block used for maths and footnotes.
- Math bold, italic, script and fraktur all come from Mathematical Alphanumeric Symbols, a block many fonts skip entirely. This is the risky group.
- Combining-mark effects depend on the renderer’s combining-mark support rather than glyph coverage, so they fail differently and less predictably.
There is a pattern here worth noticing: the styles people actually use most are also the safest ones. That is probably not a coincidence — a style that renders as boxes for half your audience does not get adopted.
What to do
Test on a second device before committing. Not a preview inside a generator — an actual different phone or computer, ideally an older one. This is the only real test.
Prefer small caps for anything that matters. It has the widest font coverage of the decorative styles and stays legible at name size.
Keep essential information in plain text. Your handle, a link, a name someone needs to read — these should never depend on the reader’s font. Style the decoration, not the content.
If someone reports boxes, ask what device. The answer is almost always an older phone or a device with a custom font, and that tells you whether to change the style or accept the loss.
The one thing it is not
It is not the generator “producing broken characters,” and re-copying will not help. The bytes are correct. You are looking at a rendering gap on one device, and the same text may look perfect on the next one.
Related: why q and x look wrong in small caps — a different problem with a similar symptom, but that one is about Unicode itself rather than the font.