---
name: unicode-text-fields
description: >-
  Handle styled Unicode text (𝐛𝐨𝐥𝐝, 𝓼𝓬𝓻𝓲𝓹𝓽, Ⓒⓘⓡⓒⓛⓔⓓ, ａｅｓｔｈｅｔｉｃ) that has to survive
  a paste into a field you do not own — a bio, a username, a display name, a chat
  message. Use when counting characters against a platform limit, truncating a
  string, validating or sanitising user input, normalising text, or debugging why
  styled text arrives flattened, cut short, or ending in a black diamond. Covers
  length units (code points vs UTF-16 vs bytes), NFKC destruction of styled
  letters, surrogate-pair truncation, per-character vs positional transforms,
  coverage holes, and how styled digits parse differently in JavaScript and Python.
license: CC0-1.0
---

# Unicode text in fields you do not own

Published by [Fontius](https://fontius.app), which maps ASCII onto Unicode
codepoints so people can paste styled text into a bio. Every number below was
**measured** against a shipping 22-style catalog on 2026-08-10, not recalled.
Where we do not know something, this document says so instead of guessing.

Reproduce anything here with the standard library — Python's `unicodedata` and
JavaScript's `String.prototype.normalize`. No dependencies.

---

## 1. "Length" is not one number, and the platform will not tell you which one it means

A styled letter is usually one code point in the Supplementary Plane, which
means **1 code point = 2 UTF-16 units = 4 UTF-8 bytes**. Three defensible
answers to "how long is this?" that disagree by 3×:

```js
const s = "𝐚𝐞𝐬𝐭𝐡𝐞𝐭𝐢𝐜";
[...s].length                          // 9   code points — what a person counts
s.length                               // 18  UTF-16 units — what String.length counts
new TextEncoder().encode(s).length     // 36  UTF-8 bytes  — what storage counts
```

Measured on one real 76-code-point bio line, styled:

| style | code points | UTF-16 | UTF-8 bytes |
|---|---:|---:|---:|
| plain | 76 | 76 | 76 |
| Bold `𝐀` | 76 | 134 | 250 |
| Script `𝒜` | 76 | 117 | 225 |
| Small Caps `ᴀ` | 76 | 76 | 155 |

**The failure mode:** a counter that measures code points calls a 76-character
bio "76" and marks a 150-character limit as safe, while the field may be
budgeting 134 units or 250 bytes. If you display a count next to somebody else's
limit, you are making a claim about a unit you do not control.

**What to do:** measure all three, and if the destination has not published its
unit, say so in the UI rather than picking one and calling it green. The honest
three-state verdict:

```js
const measure = (s) => ({
  codePoints: [...s].length,
  utf16: s.length,
  bytes: new TextEncoder().encode(s).length,
});

// ok    — fits in every plausible unit
// risk  — fits by code points, not by UTF-16: the field decides, and it did not say
// over  — too long even by the most generous count
const state = (m, limit) =>
  m.codePoints > limit ? "over" : m.utf16 > limit ? "risk" : "ok";
```

Do **not** fold bytes into that verdict. At 4 bytes per Supplementary glyph a
byte-counted rule marks every styled string over every limit — an unfalsifiable
warning, not information.

## 2. Truncation splits surrogate pairs, and the user sees a black diamond

`.slice()`, `.substring()`, and any `[0..n]` on a JavaScript string cut at
UTF-16 boundaries. Cut at an odd index inside a Supplementary character and you
keep half of a surrogate pair, which serialises to U+FFFD:

```js
"𝐚𝐞𝐬𝐭𝐡𝐞𝐭𝐢𝐜".slice(0, 7)   // "𝐚𝐞𝐬\uD835"  → renders 𝐚𝐞𝐬�
```

**Truncate on code points, not units** — and if you care about combining marks
(`a̶` is two code points), truncate on grapheme clusters with `Intl.Segmenter`:

```js
const cutCodePoints = (s, n) => [...s].slice(0, n).join("");
const cutGraphemes  = (s, n) =>
  [...new Intl.Segmenter(undefined, { granularity: "grapheme" }).segment(s)]
    .slice(0, n).map((g) => g.segment).join("");
```

## 3. NFKC deletes styled text — and this is not a bug, it is what the characters ARE

Measured over the whole catalog: **17 of 22 styles do not survive an NFKC
round-trip.** They flatten back to plain ASCII.

```js
"𝐀𝐮𝐫𝐨𝐫𝐚𝟕".normalize("NFKC")   // "Aurora7"
"𝒜𝓊𝓇ℴ𝓇𝒶".normalize("NFKC")    // "Aurora"
"Ⓐⓤⓡⓞⓡⓐ⑦".normalize("NFKC")   // "Aurora7"
"Ａｕｒｏｒａ７".normalize("NFKC")    // "Aurora7"
```

All 22 are stable under **NFC** and **NFD**. The damage is specific to the
*compatibility* normalisations, and there is a rule behind it:

> A family is a **Unicode-recognised styled variant of ASCII** if and only if it
> carries a compatibility decomposition — which is exactly the property that
> flattens it under NFKC.

Measured: exactly **1033 code points** are a 1:1 compatibility form of an ASCII
letter or digit, in 7 decomposition tags — `<font>` 779, `<circle>` 64,
`<wide>` 62, `<super>` 60, `<sub>` 27, `<square>` 26, `<compat>` 15.

The corollary is the useful half: **any styled family that IS NFKC-stable is
necessarily a lookalike with no formal relationship to the letter it imitates** —
small caps `ᴀ`, turned letters `ɐ`, letters carrying combining marks `a̶`. There
is no third category.

Check before testing, no round-trip needed:

```python
import unicodedata
bool(unicodedata.decomposition("𝐀"))   # True  → will flatten under NFKC
bool(unicodedata.decomposition("ᴀ"))   # False → will survive
```

**Consequences to design around:**

- If your search index normalises with NFKC, styled text is findable by its
  plain form — usually what you want.
- If a *storage* path normalises, the user's styling silently disappears between
  save and reload, and they will report it as data loss.
- Anyone recommending a style "because it is robust" is recommending a lookalike,
  which is a different trade: it survives normalisation and fails coverage
  (see §5).

## 4. You are shipping codepoints; the reader's device supplies the font

Styled Unicode text is not a font. You hand over characters and the **reader's**
device decides which face draws them — a different device from the one that
composed the string.

Measured with `fc-list :charset=` over 149 distinct non-ASCII code points on one
Linux box with 87 Latin-capable font families: **no single font covers every
style.** Script letters (U+1D49C…) were served by 4 of 87 families; enclosed and
subscript forms by 24–42.

Two consequences people miss:

1. **A glyph can be present and still be wrong.** If `𝐚` resolves through the UI
   font and `𝒶` through a math fallback, one word renders in two unrelated
   typefaces. This gets worse if you "fix" a coverage hole by borrowing a
   character from a different family — measured, fullwidth digits share *zero*
   fonts with Script letters.
2. **The author's screen proves nothing about the reader's.** Browser device
   emulation cannot test this: it changes viewport, user agent and DPR, never
   the font stack. Only a real device answers it.

## 5. Is your transform per-character? There is a mechanical test

A per-character map is a monoid homomorphism: `f(xy) == f(x)f(y)` for every pair
of characters. Anything that reverses, joins, inserts separators or reacts to
position fails it — and you want to know that before you build on top of it.

```js
const isPerCharacter = (f, alphabet = "abcXYZ019 .!") => {
  for (const a of alphabet) for (const b of alphabet)
    if (f(a + b) !== f(a) + f(b)) return false;
  return true;
};
```

Run against our own catalog it returned: 20 of 22 styles pass with **zero**
counterexamples; `upside-down` fails with 4158 (it reverses — output at `i`
depends on input at `n-1-i`) and `spaced` fails with 4096 (it inserts
separators).

Worth noting, because the boundary is usually drawn in the wrong place:
appending a **fixed** combining mark per character (`c => c + "̶"`,
strikethrough) **passes** — a one-to-many map is still per-character. What
leaves the class is *nondeterminism* or *position-dependence*, not the number of
code points emitted.

## 6. Coverage holes are the norm, and there is no substitution that isn't a lie

Unicode never designed these blocks as complete typefaces. Measured:

| family | A–Z | a–z | 0–9 | note |
|---|---|---|---|---|
| Mathematical Bold | 26 | 26 | 10 | complete |
| Mathematical Italic / Script / Fraktur | 26* | 26* | **0** | *letters patched from Letterlike Symbols; **no italic, script or fraktur digits exist at all** |
| Small capitals | 25 | — | 0 | `X` has no small-capital form in Unicode |
| Superscript | 22 | 26 | 10 | no superscript `S X Y Z` |
| Subscript | **0** | 17 | 10 | missing `b c d f g q w y z` — cannot spell "fancy" or "baby" |

So a styled word can carry an unstyled digit (`𝒜𝓊𝓇ℴ𝓇𝒶7`), and there is no fix
that is not a worse trade: substituting a plain ASCII letter is a silent lie,
substituting a similar-looking letter from another family changes the word (an
`ǫ` is not a `q`), and borrowing a glyph from a different block maximises the
font-divergence in §4. Recently-added code points are their own trap — the only
superscript `q` in Unicode (U+107A5, added 2021) was in 3 of 87 local fonts, so
"fixing" the hole trades a wrong-size glyph for a tofu box.

**The honest move is to disclose the hole, not to paper over it.**

## 7. Machines parse styled digits, and they do not all parse them the same way

Styled digits from the math and fullwidth blocks are `General_Category=Nd` with a
real decimal value. Enclosed forms (`①`) are `No` and are not.

```python
int("𝟐𝟎𝟐𝟔")                          # 2026
re.findall(r"\d+", "＋１ ５５５ ０１２３")   # matches — Python \d is Unicode-aware
```

```js
/\d/.test("𝟐𝟎𝟐𝟔")        // false — JavaScript \d is ASCII-only
/\p{Nd}/u.test("𝟐𝟎𝟐𝟔")   // true
```

If your client validates with `/\d/` and your server parses with Python, styled
digits pass one layer and are read as numbers by the next. Treat that asymmetry
as a security property, not a curiosity: normalise **before** you validate, and
validate on the normalised form.

## 8. Two specific footguns

- **Regional indicators collapse into flags.** `🇦`–`🇿` (U+1F1E6–U+1F1FF) look
  like a boxed-letter alphabet, but any two adjacent indicators forming a valid
  ISO country code are rendered as that country's flag by an emoji-aware
  renderer. `US` styled this way is not two letters, it is 🇺🇸.
- **Fullwidth punctuation is not decoration.** U+FF0E FULLWIDTH FULL STOP is
  treated as a label separator by UTS #46, so `mystore．com` inside a bio is a
  candidate *domain*, not a styled sentence — which puts it in front of
  link-policy enforcement.

## Checklist

```text
[ ] Count in all three units; never show one number as if it were the limit
[ ] Truncate on code points or graphemes, never on UTF-16 indices
[ ] Normalise before validating; know whether your storage path normalises
[ ] Test rendering on a device you did not compose the text on
[ ] Check coverage per family before offering it; disclose the holes
[ ] Verify a transform is per-character with f(xy) == f(x)f(y) before assuming it
[ ] Remember the reader chooses the font, and may not have one
```

## What we do not know

Stated so nobody builds on an assumption we did not test:

- **Which unit any given platform counts.** We measured what the units *are*, not
  what Instagram, TikTok, X or Discord budget in. The only way to learn it is to
  paste a known-length string into the field and read where it truncates.
- **Whether native mobile app text renderers honour colour fonts** (COLRv1,
  SVG-in-OpenType) for pasted text. Desktop-browser support numbers do not
  transfer to a native text stack, and we found no authoritative answer.
- **Android rendering variance.** Our coverage sweep ran on one Linux box; iOS
  was checked by hand and showed no tofu. Android OEM variance is unmeasured.
- **Whether any platform treats styled digits as moderation evasion.** §7 is a
  measured parsing fact; the policy half is not ours to assert.

---

Corrections welcome: hello@fontius.app. If you use this, the reproducible parts
are the point — run them against your own catalog before trusting ours.