Why Unicode fonts break in some apps and not others

The most common support question about text generators is some version of “why does it look right on my phone but wrong on my friend’s?” The answer is always the same, and it is worth understanding once rather than guessing every time.

Styled text is characters, not formatting

When you bold a word in a document, the letters stay the same and the application records a separate instruction: draw these from the bold cut of the typeface. Strip the formatting and the word is still there.

Unicode styling works the other way round. There is no instruction. The bold A is a different character from the plain A, with its own code point, its own name and its own place in the standard. Copying it copies the character itself, which is exactly why it survives a paste into an Instagram bio, a Discord nickname or an X post, none of which offer formatting.

The cost is that you are now depending on two things you do not control: the receiving app’s willingness to accept the character, and the reader’s device having a font that can draw it.

Where it breaks, and why

Missing glyph, shown as a box. The character arrived intact but the font on that device has no drawing for it. You see ▯ or a box with hex digits. Nothing is corrupted; the text is fine and will render on a device with better font coverage. Older Android builds and stripped-down embedded browsers are the usual culprits, and the mathematical alphanumeric ranges are the most commonly missing.

The app rejects the character. Some platforms validate usernames against an allowlist and will refuse anything outside it. This is a policy decision, not a rendering failure, and no generator can work around it. Display names are usually permissive; account handles usually are not.

The app normalises the text. A few platforms run Unicode normalisation on input, which can fold styled characters back to their plain equivalents. Your bold text silently becomes ordinary text on save. Nothing is broken; the platform decided the two were equivalent.

Combining marks overflow. Underlines, strikethroughs and Zalgo marks are zero-width: they are drawn on top of the preceding character without reserving space. Stack enough of them and they spill over the line above or below, and some apps clip the overflow rather than expanding the line.

The parts that are genuinely incomplete

It is worth being honest about coverage rather than implying every style handles every input.

Script, fraktur and the italic styles have no digits in Unicode, so numbers pass through unchanged. Filled circled and both squared styles are uppercase only, so lowercase input maps to the uppercase glyph. Small caps has no letter X, so an x stays lowercase. No style covers accented characters, so é and ñ pass through as themselves.

A generator that hides this by silently dropping unmapped characters is lying to you about what you are about to paste.

Reading it with a screen reader

This matters more than it usually gets credit for. A screen reader announces characters by their Unicode names. A word set in mathematical bold may be read out as a sequence of formal character names rather than as the word, and a heavily Zalgo-corrupted string can produce a long recitation of combining-mark names.

If the text carries meaning that someone needs, such as your actual name in a profile, put the plain version somewhere too. Decorative styling on a display name is fine. Styling the only copy of important information is not.

A practical approach

Test in the destination before you commit to it, not in the generator’s own preview. Prefer styles built on the mathematical alphanumeric block for the widest support. Keep heavy combining-mark effects for places where they are the point, such as a Discord message, rather than a username you will live with.

And if a style does not render where you need it, that is information about that platform’s font stack, not about the text you copied.