DEV Community: Mohsin Qureshi

How Unicode Mathematical Alphabets Became Social Media's Font System

Mohsin Qureshi — Tue, 04 Aug 2026 18:48:16 +0000

Social media has no font controls. Instagram offers no bold button. Discord has no cursive setting. TikTok gives you exactly one typeface. And yet styled text is everywhere — cursive bios, gothic server names, bold display names. Every one of them runs on the same underlying mechanism, and it is not what most people think.

The mechanism in one sentence

A "fancy font generator" does not apply fonts. It substitutes each input character with a visually similar character from a different Unicode block.

Your regular A is U+0041. Mathematical Bold Capital A is U+1D400. They look related but they are entirely different code points. Copy 𝐀 into any plain-text field and it survives — because it is not formatting, it is a character.

The mapping in code

The entire engine of every fancy text tool is a lookup table and a map operation:

const BOLD = {
  A: '\u{1D400}', B: '\u{1D401}', C: '\u{1D402}',
  D: '\u{1D403}', E: '\u{1D404}', F: '\u{1D405}',
  // ... full A-Z
  a: '\u{1D41A}', b: '\u{1D41B}', c: '\u{1D41C}',
  // ... full a-z
};

function convert(text, charMap) {
  return [...text]
    .map(char => charMap[char] || char)
    .join('');
}

convert('Hello', BOLD); // '𝐇𝐞𝐥𝐥𝐨'

Three implementation details that matter:

Spread syntax over split(''). The [...text] spread iterates by code point, not by UTF-16 code unit. Input containing emoji or supplementary-plane characters will break with split('') because it splits surrogate pairs. Every fancy text tool that uses split('') has this bug — most just never notice because typical input is ASCII.

Fallthrough for unmapped characters. The || char keeps spaces, digits, and punctuation intact. Without it, spaces become undefined and the output is garbage.

Curly-brace escapes for supplementary plane. \u{1D400} requires the braces because the code point exceeds U+FFFF. Writing \u1D400 (no braces) compiles as \u1D40 followed by literal 0 — a silent bug that produces wrong output for exactly one character position.

The alphabets available

Unicode provides these mathematical alphabet variants, each in its own block:

Style	Lowercase example	Block range
Bold Serif	𝐚𝐛𝐜	U+1D400–1D433
Italic	𝑎𝑏𝑐	U+1D434–1D467
Bold Italic	𝒂𝒃𝒄	U+1D468–1D49B
Script (cursive)	𝒶𝒷𝒸	U+1D49C–1D4CF
Bold Script	𝓪𝓫𝓬	U+1D4D0–1D503
Fraktur (gothic)	𝔞𝔟𝔠	U+1D504–1D537
Bold Fraktur	𝖆𝖇𝖈	U+1D56C–1D59F
Double-struck	𝕒𝕓𝕔	U+1D538–1D56B
Monospace	𝚊𝚋𝚌	U+1D670–1D6A3
Sans-serif	𝖺𝖻𝖼	U+1D5A0–1D5D3
Sans Bold	𝗮𝗯𝗰	U+1D5D4–1D607
Sans Italic	𝘢𝘣𝘤	U+1D608–1D63B
Sans Bold Italic	𝙖𝙗𝙘	U+1D63C–1D66F

That is 13 complete Latin alphabets — uppercase and lowercase — sitting in Unicode primarily because mathematicians needed them for notation.

The gaps that break naive implementations

This is where most implementations fail. Several alphabets have "holes" — code points that were never assigned because the character already existed elsewhere in Unicode under a different name.

// Mathematical Italic is missing lowercase h
// U+1D455 was reserved but never assigned
// The correct character is U+210E (Planck constant)
const ITALIC = {
  // ...
  h: '\u210E',  // NOT '\u{1D455}'
  // ...
};

The pattern repeats across multiple alphabets:

Script: e → U+212F, g → U+210A, o → U+2134
Fraktur: C → U+212D, H → U+210C, I → U+2111, R → U+211C, Z → U+2128
Double-struck: C → U+2102, H → U+210D, N → U+2115, P → U+2119, Q → U+211A, R → U+211D, Z → U+2124

These characters live in the Letterlike Symbols block (U+2100–U+214F), not in the Mathematical Alphanumeric Symbols block. A generator that naively computes character offsets without handling these exceptions will output undefined or a wrong character for specific letters — a bug that is invisible unless someone types a word containing one of the affected letters.

Combining marks — the second mechanism

Beyond alphabet substitution, Unicode has combining characters that stack onto the preceding base character:

function strikethrough(text) {
  return [...text]
    .map(char => char === ' ' ? ' ' : char + '\u0336')
    .join('');
}

strikethrough('deleted'); // 'd̶e̶l̶e̶t̶e̶d̶'

U+0336 (Combining Long Stroke Overlay) has zero advance width — it renders directly on top of the character before it. The same principle gives you:

Underline: U+0332
Overline: U+0305
Double underline: U+0333
Dot above: U+0307
Zalgo (stacked chaos): multiple combining marks per character

The space check (char === ' ') matters because combining marks on whitespace render as floating diacritics, which looks broken rather than styled.

Cross-device rendering: what actually works

Every styled character needs a font on the receiving device that contains it. Modern iOS, Android, and desktop operating systems ship fonts covering the full Mathematical Alphanumeric Symbols block. The practical coverage:

Style	iOS	Android	Windows	Coverage
Bold/Italic/Bold Italic	✅	✅	✅	Universal
Script (both weights)	✅	✅	✅	Universal
Fraktur (both weights)	✅	✅	✅	Universal
Double-struck	✅	✅	✅	Universal
Monospace	✅	✅	✅	Universal
Sans variants	✅	✅	✅	Universal
Rare combining stacks	⚠️	⚠️	⚠️	Varies

The mainstream styles work everywhere. Exotic combining-character stacks (heavy zalgo, multi-diacritic effects) render inconsistently on budget Android devices that ship with minimal font coverage.

The accessibility cost

Screen readers do not recognize mathematical alphabet characters as their plain-text equivalents. NVDA encountering 𝗛𝗲𝗹𝗹𝗼 may read it as "mathematical sans-serif bold capital H, mathematical sans-serif bold small e..." — one Unicode name per character.

For decorative display text (usernames, bio taglines), this is an accepted trade-off. For anything informational — instructions, descriptions, critical content — real formatting (CSS font-weight, markdown **bold**) is correct and styled Unicode is wrong.

Tools that surface this distinction rather than hiding it serve their users better than tools that pretend every context is appropriate for character substitution.

Search implications

Styled characters and plain characters are distinct code points. A search for "admin" will not match "𝗮𝗱𝗺𝗶𝗻" on any platform — they share zero characters in common. This has real consequences:

Styled Discord channel names are unsearchable by their apparent name
Styled hashtags reach nobody (they are different tags)
Styled usernames cannot be @mentioned by typing the visible name

These are not bugs — they are the logical consequence of the styling being characters rather than formatting.

Building one yourself

A complete implementation needs three things:

Correct character maps — including Letterlike Symbols block exceptions
Combining mark functions — for strikethrough, underline, and decorative effects
A normalization function — to strip existing styled characters back to ASCII before re-converting

The normalization matters for paste-in scenarios: if a user pastes already-styled text and tries to convert it to a different style, you need to reverse the first conversion before applying the second.

function normalize(text) {
  return [...text].map(char => {
    const cp = char.codePointAt(0);
    // Check each mathematical block range
    // and map back to basic Latin
    if (cp >= 0x1D400 && cp <= 0x1D419) 
      return String.fromCharCode(65 + cp - 0x1D400); // Bold A-Z
    if (cp >= 0x1D41A && cp <= 0x1D433) 
      return String.fromCharCode(97 + cp - 0x1D41A); // Bold a-z
    // ... repeat for each block
    return char;
  }).join('');
}

The full implementation is longer but mechanical — each block follows the same offset pattern with its specific exceptions.

Why this matters beyond fun

Unicode mathematical alphabets were added to the standard for academic typesetting. Their current primary use — making Instagram bios look fancy — was entirely unintended. But it solves a real problem: platforms that accept text but offer no formatting. Until Instagram adds a bold button or Discord lets you choose a bio font, character substitution remains the only way to style text in those contexts.

The engineering is trivial. The edge cases are not. Getting the Letterlike Symbols exceptions right, handling surrogate pairs in input, managing combining mark stacking, and testing cross-device rendering is where amateur implementations diverge from correct ones.

If you want to see how different organizational approaches to the same underlying mechanism feel from a user perspective, this tool groups 200+ variations by visual category while handling all the exception cases covered above.

Build a Unicode Text Style Converter in JavaScript

Mohsin Qureshi — Sun, 26 Jul 2026 06:15:20 +0000

Every social media bio in a fancy font, every Discord username in gothic letters, every "fancy text generator" tool — they all run on the same twenty-line JavaScript trick. No libraries, no fonts, no rendering engine. Just a character map and a String.prototype.split call.

I want to show you exactly how it works, because once you see the pattern you can build one in about ten minutes.

The core insight

Unicode reserves entire alphabets for mathematical notation. Bold serif A through Z. Italic. Monospace. Fraktur. Double-struck. Script. These were added for math papers but they render on every modern device because they are part of the Unicode standard, not a font file.

Regular capital A is code point U+0041. Mathematical Bold Capital A is U+1D400. Different characters, same visual meaning. Copy 𝐀 and paste it into a form that only accepts plain text — it goes through, because it is plain text, just a different code point.

A "font style generator" is not styling anything. It is swapping every character in your input for the visually equivalent character in a mathematical alphabet.

The mapping

Here is the entire lookup table for bold serif:

const BOLD_SERIF = {
  a: '\u{1D41A}', b: '\u{1D41B}', c: '\u{1D41C}', d: '\u{1D41D}',
  e: '\u{1D41E}', f: '\u{1D41F}', g: '\u{1D420}', h: '\u{1D421}',
  i: '\u{1D422}', j: '\u{1D423}', k: '\u{1D424}', l: '\u{1D425}',
  m: '\u{1D426}', n: '\u{1D427}', o: '\u{1D428}', p: '\u{1D429}',
  q: '\u{1D42A}', r: '\u{1D42B}', s: '\u{1D42C}', t: '\u{1D42D}',
  u: '\u{1D42E}', v: '\u{1D42F}', w: '\u{1D430}', x: '\u{1D431}',
  y: '\u{1D432}', z: '\u{1D433}',
  A: '\u{1D400}', B: '\u{1D401}', C: '\u{1D402}', D: '\u{1D403}',
  E: '\u{1D404}', F: '\u{1D405}', G: '\u{1D406}', H: '\u{1D407}',
  I: '\u{1D408}', J: '\u{1D409}', K: '\u{1D40A}', L: '\u{1D40B}',
  M: '\u{1D40C}', N: '\u{1D40D}', O: '\u{1D40E}', P: '\u{1D40F}',
  Q: '\u{1D410}', R: '\u{1D411}', S: '\u{1D412}', T: '\u{1D413}',
  U: '\u{1D414}', V: '\u{1D415}', W: '\u{1D416}', X: '\u{1D417}',
  Y: '\u{1D418}', Z: '\u{1D419}'
};

The converter

function convert(text, map) {
  return [...text].map(ch => map[ch] || ch).join('');
}

convert('Hello World', BOLD_SERIF);
// '𝐇𝐞𝐥𝐥𝐨 𝐖𝐨𝐫𝐥𝐝'

Three things worth noticing:

[...text] instead of text.split('') — the spread operator splits by Unicode code points rather than UTF-16 code units. If the input already contains emoji or supplementary-plane characters, split('') breaks them in half. Spread iterates code points correctly.

map[ch] || ch — anything not in the map (spaces, digits, punctuation, emoji) falls through unchanged. That preserves whitespace and any pre-existing symbols in the input.

Unicode escapes use \u{...} syntax — the curly braces are required for code points above U+FFFF, which is where most of the mathematical alphabets live. \u1D41A (without braces) does not work — it parses as \u1D41 followed by the literal string A.

Adding more styles

Every style is just another map. Italic:

const ITALIC = {
  a: '\u{1D44E}', b: '\u{1D44F}', c: '\u{1D450}', // ...
  h: '\u{210E}', // exception — h has a legacy code point
  // ...
};

Watch out for that italic h (ℎ, U+210E). Unicode reserves U+1D455 but never assigned it — the character was already defined elsewhere as "Planck constant" and Unicode does not duplicate. Same trap exists in script (e, g, o), Fraktur (C, H, I, R, Z), and double-struck (C, H, N, P, Q, R, Z). Your mapping table must reach into the Letterlike Symbols block (U+2100–U+214F) for these exceptions or you will emit undefined characters.

Combining marks — a different mechanism

Bold, italic, and script are alphabet substitutions. Strikethrough and underline work differently: they use combining marks that stack on top of a base character.

function strikethrough(text) {
  return [...text].map(ch => ch === ' ' ? ' ' : ch + '\u0336').join('');
}

strikethrough('cancelled');
// 'c̶a̶n̶c̶e̶l̶l̶e̶d̶'

U+0336 is Combining Long Stroke Overlay. It has zero visual width — it renders on top of the character that immediately precedes it. The same pattern gives you underline (U+0332), overline (U+0305), dot above (U+0307), and dozens of others.

Spaces get skipped in the map because combining marks on spaces render as isolated diacritics floating in whitespace, which looks broken.

Handling paste-in from users

If you accept text from a user, they may paste something that already contains styled characters. Trying to re-map 𝓗𝓮𝓵𝓵𝓸 through your bold-serif table produces garbage because your table only knows about basic Latin letters.

The pragmatic fix is normalizing to plain ASCII before converting:

function normalize(text) {
  const RANGES = [
    [0x1D400, 0x1D433], // bold serif
    [0x1D434, 0x1D467], // italic
    [0x1D468, 0x1D49B], // bold italic
    // ...add ranges as needed
  ];

  return [...text].map(ch => {
    const code = ch.codePointAt(0);
    for (const [start] of RANGES) {
      if (code >= start && code < start + 52) {
        const offset = (code - start) % 26;
        const isUpper = (code - start) < 26;
        return String.fromCharCode((isUpper ? 65 : 97) + offset);
      }
    }
    return ch;
  }).join('');
}

This reverses the mapping — anything within a known mathematical alphabet range gets pulled back to plain A–Z or a–z before you re-convert.

Where the ecosystem sits

Every Unicode font tool on the internet — the kind users hit when searching for a font generator — runs some variation of the pattern above. The differentiation is not in the algorithm, it is in the curation. Which combinations of alphabet substitution and combining marks and symbol frames produce styles people actually want to copy.

I built livefontgenerator.com around this exact code, and after a few thousand daily users the interesting engineering problems all turn out to be UX ones — how do you show 200+ styles without overwhelming the input latency, how do you organize them so users find their aesthetic in under ten seconds, how do you handle the copy-paste flow on mobile Safari (spoiler: navigator.clipboard.writeText is finally reliable in 2026, but a fallback still helps).

If you want to see how different organizational approaches feel, the same core converter runs three different UIs at font style generator (category tabs) and fancy text generator (randomized frames) — same 30 lines of JavaScript under the hood, completely different products from a user's perspective.

The accessibility caveat

One thing worth flagging if you ship this to real users: screen readers do not treat mathematical alphabet characters as regular letters. NVDA and JAWS often read them character-by-character with their full Unicode name, which makes styled bios essentially unreadable for blind users.

For a fun tool this is fine — the styled text is the product. But if you build this into anything that matters for accessibility (form labels, headings, meaningful content), use CSS font-weight and font-style instead. Real formatting for real information, Unicode tricks for decoration.

Try it

Copy the BOLD_SERIF map and convert function above into a browser console right now. Paste some text. It just works.

That is the entire technology behind an industry of "font generators" — one lookup table, one .map().join(''), and a couple of hundred thousand daily users who have no idea their fancy bio is really six code points from a math paper.