Those "fancy fonts" in Instagram and TikTok bios aren't fonts — they're Unicode

You paste 𝓱𝓮𝓵𝓵𝓸 into an Instagram bio and it just works — no app, no image, no CSS. Copy it back out and it survives. That's the tell that it was never a font at all. It's Unicode.

Here's what's actually happening, why it travels everywhere, and the three gotchas worth knowing if you ever build or debug one of these.

A "font" changes how a glyph is drawn. This changes the character.

A real font — bold, italic, a script typeface — is a rendering instruction layered on top of the same underlying character. The letter h stays U+0068 LATIN SMALL LETTER H; the font just paints it differently. Strip the styling and you still have h.

Fancy text works the other way around. 𝓱 is not an h wearing a costume — it's a different code point: U+1D4F1 MATHEMATICAL SCRIPT SMALL H. Unicode shipped whole parallel alphabets, mostly for mathematicians who need a "script H" and a "bold H" to mean different things in one equation. Generators just borrow those alphabets for aesthetics.

The blocks you see most often:

• Mathematical Alphanumeric Symbols (U+1D400–U+1D7FF): bold, italic, script, fraktur, double-struck, monospace, sans-serif.
• Enclosed Alphanumerics (U+2460–U+24FF): the ⓑⓤⓑⓑⓛⓔ circled letters.
• Halfwidth and Fullwidth Forms (U+FF00–U+FFEF): the ｗｉｄｅ vaporwave spacing.
• Plus scattered small-caps, superscripts, and regional-indicator pairs (flag emoji).

Why it survives a copy-paste into any bio

Because the styling lives in the character, not in CSS, it travels as plain text. A bio field just stores a Unicode string; it has no idea that some of those code points happen to look like a curly H. That "the style rides along with the text" property is exactly why these spread — the output is portable by construction, so it carries into places that never gave you a formatting toolbar.

Generating it is just a lookup table

There's no clever algorithm here. You map each ASCII letter to the same offset inside the target block:

// ASCII A–Z → Mathematical Script uppercase, which starts at U+1D49C
const script = (ch) => {
  const i = ch.charCodeAt(0) - 65;            // A = 0
  if (i < 0 || i > 25) return ch;             // leave non-letters alone
  return String.fromCodePoint(0x1D49C + i);   // 𝒜, ℬ, 𝒞, …
};
[..."HELLO"].map(script).join("");            // 𝓗𝓔𝓛𝓛𝓞

…then you keep one table per style. The reason a ready-made fancy text generator can show dozens of styles at once is just dozens of these maps applied in parallel — the same trick powers variants like bubble text.

The three gotchas nobody mentions

The fun stops the moment this text meets a machine instead of a human eyeball:

1. Accessibility takes a hit. A screen reader doesn't see a stylish H — it sees MATHEMATICAL SCRIPT SMALL H, and will either read that aloud literally or skip the character. A bio written entirely in fancy text can be unreadable to assistive tech. Use it for a flourish, not your whole name.

2. It's invisible to search and matching. 𝓳𝓸𝓱𝓷 and john are different byte sequences, so naïve search, @-mentions, and username lookups won't connect them. If you store user-supplied text, this will bite you.

3. Normalization folds it back — and that's the fix. Run the string through Unicode NFKC normalization and most of these styles collapse back to plain ASCII:
   

"𝓳𝓸𝓱𝓷".normalize("NFKC"); // "john"

That one line is how you make fancy text searchable, validate a username, or strip decoration server-side.

So the whole thing is: Unicode has spare alphabets, the styling is baked into the code point rather than the CSS, and NFKC is the undo button. Handy to know whether you're decorating a bio or sanitizing one.

Comments

[Dang Phong]

Really enjoyed this explanation, particularly how you distinguish actual fonts from Unicode character substitution. The accessibility and search limitations are also important points that many fancy-text tutorials overlook.

One small implementation detail might be worth clarifying in the Mathematical Script example.

The Script alphabet is not fully contiguous. For example, Mathematical Script Capital A is U+1D49C, but Script Capital B is ℬ (U+212C), inherited from the Letterlike Symbols block.

This means adding an ASCII letter offset to U+1D49C will not reliably produce the correct Script character for every letter.

An explicit mapping table would be a safer approach, particularly when supporting multiple Unicode styles.

The Unicode Consortium's character chart documents these assignments.

There is also a related technical discussion of mapping gaps and styled Unicode transformations.

Disclosure: I am affiliated with Levenshtein.net.

Thanks again for the accessible explanation. A brief note about these historical mapping gaps could help developers avoid a subtle bug when implementing the example.