Tofu & rendering gaps · U+1D400 block
Looks fine on most modern devices — but a font gap on the viewer's side can turn this into boxes or missing letters.
Why Fancy Text Isn’t Working: A Diagnostic Guide
By fontgenerator.tech team · Published 2026-09-06 · Reviewed 2026-09-06
"Not working" usually means one of four different things. This is a general technical guide based on how these mechanisms behave, not a report of us reproducing every specific app version — if you can tell us the exact app and what you saw, let us know and we'll investigate.
Symptom 1: boxes, question marks, or missing letters ("tofu")
This means the font actually rendering your text has no glyph for that code point. It's a font gap, not a copy-paste failure — the character pasted correctly, but nothing exists in that font to draw it. Modern iOS/Android/major browsers cover the Mathematical Alphanumeric Symbols block well; it's more common on older devices, some desktop email clients, or apps that force a narrow custom font. Fix: try a different app, or use a style with better native support (our monospace and fullwidth styles use very widely-supported ranges) — or switch to plain text.
Symptom 2: copy or paste silently does nothing
In this tool specifically, if the Clipboard API write is rejected (blocked permission, insecure context, an unsupported browser), we show a selectable text box and keyboard/long-press instructions instead of a false success message — we never claim "Copied" unless the browser actually confirmed the copy. If a different site behaves this way, check that you're not in a locked-down browser mode (private tabs in some browsers restrict clipboard access) and try the manual select-and-copy fallback.
Symptom 3: the destination field rejects your text entirely
Some fields — most notably a Discord username or many signup "full name" fields — actively restrict input to a fixed character set and will reject Unicode-substituted characters outright. This isn't a bug in the generator; it's the destination field's own validation. Check whether you're in the right field — see our Discord field guide — a display name/nickname field is usually far more permissive than a username field.
Symptom 4: it looked right when you posted, but changed later
A few platforms apply their own text normalization or content filtering after you post, which can alter or strip unusual Unicode ranges. We haven't catalogued this behavior per platform yet (see testing methodology for current status) — if you notice it, that's useful evidence for us, not something we can currently promise won't happen.
A decision tree you can actually follow
| What you see | Most likely cause | Try this first |
|---|---|---|
| Boxes/□/tofu in place of letters | Font gap on the viewing device | Try monospace or fullwidth style; or plain text |
| Some letters fine, others missing | Partial style coverage (see the style's Details panel) | Check the "kept as original text" count on the result row |
| Copy button does nothing / no confirmation | Clipboard permission blocked by the browser | Use the manual select-and-copy box we show automatically |
| Pasted, but the field won't accept it | Destination field validates characters | Check you're in the right field (see platform guides) |
| Looked right, changed after saving/posting | Platform-side normalization after submission | Report it to us with the exact platform/field |
Why we can't just "fix" boxes/tofu for you
Font coverage is entirely up to the device and app rendering your text, not the text itself, and not this generator. Two identical copies of the same styled string can render perfectly on one phone and as boxes on a five-year-old feature phone browser, because the difference is which fonts happen to be installed where the text is displayed — something no website can inspect or control. This is exactly why every style page here shows exact letter/digit coverage instead of a blanket "works everywhere" claim: we can tell you precisely which Unicode characters a style uses, but not which fonts a given viewer has.
A quick self-check before you assume it's broken
- Paste your original plain text somewhere safe first, so you never lose it while troubleshooting.
- Check the result row's coverage label (for example "18/19 characters supported") — a low number means the style itself doesn't cover most of your text, which isn't the same problem as a rendering failure.
- Try the same styled text in a different app on the same device. If it renders fine elsewhere, the problem is that specific app's font or filtering, not the text.
- Try a different, more widely-supported style (fullwidth and monospace use ranges with broad, long-established support) to see if the issue is style-specific.
If none of these fit
Try converting back to plain text to confirm the original words are intact, and consider a simpler, more widely-supported style (fullwidth and monospace tend to render most consistently). We do not attempt to detect which app you're pasting into or guarantee any specific app's behavior — see our compatibility evidence policy for why.
What "we'll investigate" actually means
If you report a specific failure through Contact, the most useful details are the exact app and version, the specific field (a bio vs. a message vs. a username, for example), the style you used, and what you actually saw — a screenshot helps enormously. That's the same kind of information our own compatibility records track (see the tables on the Instagram and Discord pages), and a real report from a real user is exactly the kind of evidence that turns a "not yet tested" row into a verified one.
Questions people actually ask
Is there a style that's guaranteed to always work? No style is guaranteed, but fullwidth and monospace draw from Unicode ranges with a long history of broad font support, so they tend to be the safest choice when you've had rendering trouble elsewhere.
Can you tell me if my specific app (name a platform) will accept this? Only if we've actually tested that exact field — see the compatibility tables on our Instagram and Discord pages. A generic statement like "works on all apps" would be a guess dressed up as a fact, and we'd rather tell you what we don't know.
Why does the character count on my platform not match what this site shows? Platforms often count differently (raw code points or UTF-16 units instead of visible characters) — see our counting guide for exactly why.