Bold, Italic and Script Unicode Letters: Exact Mathematical Alphabets, Mapping and Exceptions

Styled Unicode is encoded data, not a typeface

A heading made bold with CSS and a heading composed of mathematical bold Unicode letters are different kinds of text. CSS can draw the ordinary LATIN CAPITAL LETTER A (U+0041) in a heavy font while the encoded content stays U+0041. Replacing it with MATHEMATICAL BOLD CAPITAL A (U+1D400) changes the stored character. The latter is a distinct scalar value, typically four UTF-8 bytes and two UTF-16 code units, not a font instruction attached to U+0041.

The Unicode Standard encodes mathematical alphanumeric alphabets because different letter styles can distinguish mathematical variables after formatting is lost. It does not recommend replacing ordinary prose with mathematical letters merely to achieve typography. Nevertheless, such symbols are widely reused to create copyable styled text for plain-text fields; an implementation needs to be precise about their mathematical origin and practical tradeoffs.

This page covers bold, italic, bold italic, script and bold script letters, with special attention to why some alphabets are contiguous while others contain preexisting BMP symbols. Fraktur and double-struck have related but different historical exceptions and are documented separately in our double-struck and Fraktur reference.

The five mathematical letter styles and code-point ranges

Unicode's Mathematical Alphanumeric Symbols block occupies U+1D400..U+1D7FF, but its subdivisions are not all equally regular. In each style, the Latin uppercase and lowercase letters may be separate subranges. Greek styles and digit styles have additional coverage, and many gaps are intentional.

The basic bold Latin uppercase range U+1D400..U+1D419 and lowercase range U+1D41A..U+1D433 are contiguous. Mathematical italic Latin uppercase begins at U+1D434, bold italic uppercase at U+1D468, script uppercase at U+1D49C, and bold script uppercase at U+1D4D0. The start code points are useful, but a blanket offset applied across every style is not safe.

Bold and italic letters are a different code-point sequence from ordinary alphabetic letters even if a browser draws them similarly. They are not obtained by setting the Unicode properties Uppercase or Lowercase, and ordinary JavaScript case-mapping functions do not constitute a complete mathematical style converter. Letter styles in a document are chosen by mapping character identities, not by changing the font's font-style alone.

Script alphabet gaps and historical BMP characters

The mathematical script alphabet includes a notable set of holes because some script-shaped letters had already been encoded in the Basic Multilingual Plane's Letterlike Symbols block. To preserve character identity and avoid duplicate symbols, Unicode left the corresponding supplementary positions unassigned. For example, the alphabet's script B is U+212C ℬ SCRIPT CAPITAL B, whereas script A is U+1D49C 𝒜. A naive mapping that increments the script A code point to obtain script B would incorrectly target a gap.

Some existing letterlike symbols also have an historical or mathematical identity that differs from their apparent name. The Weierstrass elliptic function symbol U+2118 ℘, for example, is not an ordinary mathematical script capital P: its legacy name is misleading. A converter that maps capital P to that symbol because its Unicode name begins with SCRIPT would be incorrect. The correct script P has its own code point within the mathematical script alphabet where assigned; a generated mapping should be checked against the actual Unicode character name and decompositions.

Unicode identifies a set of 24 older Letterlike Symbols integrated into the larger mathematical alphabets, spread across script, Fraktur and double-struck styles and related variants. Not every alphabet has the same holes, and some symbols have distinct names despite visual similarity. Keep mapping tables for each style rather than sharing one generic offset strategy.

Why normalization exposes those historical decisions

Although U+212C ℬ lives outside the supplementary mathematical block, its NFKC compatibility decomposition is the ordinary Latin letter B, just like the decompositions of many plane-1 script symbols to their base alphabet. This is a useful verification clue but not a complete mapping definition: identical NFKC results can correspond to several distinct mathematical styles.

A safe converter and inverse lookup

For a narrow, documented style where the 26 uppercase symbols are contiguous, an offset calculation can be appropriate. For script, Fraktur and double-struck, prefer an explicit, version-checked table covering all intended letters and exceptions. Always iterate by Unicode code points using for...of, not individual UTF-16 code units, to avoid breaking supplementary characters.

// This helper intentionally supports only the verified
// mathematical bold uppercase Latin run (A–Z).
function toMathBoldCaps(input) {
  return [...input].map(ch => {
    const point = ch.codePointAt(0);
    return point >= 0x41 && point <= 0x5A
      ? String.fromCodePoint(0x1D400 + point - 0x41)
      : ch;
  }).join("");
}
console.log(toMathBoldCaps("ABC 7"));
// 𝐀𝐁𝐂 7; digit is intentionally unchanged

const scriptA = String.fromCodePoint(0x1D49C);
const scriptB = "\u212C";
console.log(scriptA, scriptB); // 𝒜 ℬ
console.log(scriptB.normalize("NFKC")); // "B"

To build a full alphabet, parse versioned UnicodeData.txt or a manually verified table; find characters with exact mathematical names and style labels, then cross-check intended Latin/Greek mappings. The algorithm should account for BMP exceptions and known unassigned holes. Do not assume every name containing BOLD or SCRIPT is a substitute for an ordinary Latin letter; mathematical Greek variants and specialized symbols have additional semantic roles.

An inverse transformation is inherently lossy if it folds multiple styles to one base letter. A function that returns "A" for both mathematical bold A and script A cannot reconstruct which style was originally chosen. Store the original source or carry the selected style identifier separately if a reversible editing experience is required.

For a public Fancy Text generator, an honest behavior is to leave unsupported code points unchanged and disclose partial coverage rather than invent a visually similar character that does not correspond to the correct letter. This is especially important for non-Latin text, accented Latin letters, digits and special punctuation.

What NFC and NFKC actually do

NFC and NFD implement canonical equivalence; they generally preserve mathematical letter style. NFKC and NFKD apply compatibility mappings and collapse most mathematical styled letters to their underlying Latin or Greek equivalents. This is intentional: two mathematically distinct variables may share a compatibility decomposition but remain separate encoded characters.

const normal = "A";
const bold = "\u{1D400}";
const italic = "\u{1D434}";
const script = "\u{1D49C}";

for (const sample of [bold, italic, script]) {
  console.log(
    sample === normal,                    // false
    sample.normalize("NFC") === sample,  // true
    sample.normalize("NFKC") === normal  // true
  );
}

Compatibility normalization is useful for certain search keys, text diagnostics and identifier restrictions; it is unsuitable as a blind write-time transformation for mathematical notation or copyable decorative output because it discards style distinctions. Keep normalized comparison keys separate from faithful display data whenever those distinctions matter.

Some Unicode formatting symbols, combining marks and unsupported characters do not have such simple NFKC-to-base-letter mappings. Therefore, the slogan “NFKC removes all fancy fonts” is inaccurate: there is no universal Unicode category named “fancy fonts,” and decorative output can combine several encoding techniques.

Glyph coverage, text shaping and accessibility

A mathematical letter is still a code point requiring font coverage. A font can support ordinary italic Latin letters while missing U+1D434. Even if both are available, their metrics and outlines can differ, and the renderer may choose a fallback math font. A stylized string may appear consistently within a single browser but differently after copy/paste into a mobile social app.

Screen readers may announce Unicode names or mathematical style qualifiers, while other assistive software may flatten letters or read them unpredictably. The pronunciation can be appropriate in a technical mathematical expression but exhausting in a decorative paragraph. Use plain language and real HTML formatting for essential instructions, navigation, form labels, and other accessibility-critical text.

The simple notion that bold always denotes a vector or script always denotes a set is not part of Unicode's character model. Those conventions depend on surrounding mathematical notation; the encoded alphabet preserves distinctions, but semantic interpretation belongs to the document's technical domain.

Copy-paste behavior and realistic compatibility limits

When a user copies mathematical bold text, the clipboard usually carries the actual supplementary code points. The destination can normalize, filter or lack font coverage. Plain ASCII A is one UTF-8 byte, while U+1D400 is four UTF-8 bytes; both can be one extended grapheme cluster. Some platform limits are counted in bytes, others in UTF-16 units or grapheme clusters, so the apparent number of characters is not sufficient to predict acceptance.

If a transformed string appears in a username, a search index might compare it as distinct from the original, treat it as compatibility-equivalent, or disallow it according to a local identifier profile. Neither Unicode validity nor identical visual appearance guarantees universal interoperability. For trust-sensitive identifiers, compare the threat model against UTS #39 confusable detection and the application's specific acceptance rules.

When building variants of a word, test a literal copy/paste round trip into the intended target app and inspect code points on both sides. Visual screenshots alone cannot show whether a receiving platform preserved a mathematical script symbol or normalized it to an ordinary letter.

Tests and diagnostic vectors

A thorough test suite enumerates the supported Latin and Greek repertoire from the UCD, validates character names and compatibility decompositions, and verifies that every generated scalar is assigned. Pin the UCD version. For rendering, add browser and mobile font-coverage checks as a separate test layer; data-level conformance cannot guarantee glyph availability.

Standards and primary datasets

1. The Unicode Standard, Chapter 22 — Mathematical Alphanumeric Symbols, intended uses and legacy exceptions.
2. Unicode Code Chart U+1D400..U+1D7FF, assigned mathematical symbols.
3. Unicode Code Chart U+2100..U+214F, BMP Letterlike Symbols.
4. UAX #15 — Unicode Normalization Forms, compatibility equivalence and stability.
5. UAX #44 — Unicode Character Database, data property definitions and names.
6. UTS #39 — Unicode Security Mechanisms, identifier and confusable considerations.

Independent reference on the Unicode mathematical character model; glyph designs and fallback vary by device and math font.