Someone signs up for your app with the display name 𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮. Your length check passes. Your profanity filter passes. Your search index has never heard of them again.
The thing most people get wrong on first contact: this is not a font. Nobody installed anything. 𝓯 is not the letter f wearing a costume — it is U+1D4EF, MATHEMATICAL BOLD SCRIPT SMALL F, a separate character with its own code point. Unicode has a whole parallel Latin alphabet (several, actually), added over the years for maths notation, phonetics and enclosed symbols, and the copy-paste generator sites turned it into a bio decoration.
That distinction has consequences all the way down your stack. Here are the five that have bitten me.
1. Your length check counts the wrong thing
const name = '𝓯𝓪𝓷𝓬𝔶';
name.length // 10
[...name].length // 5
name.slice(0, 3) // '𝓯\ud835' ← a broken half-character
Everything above U+FFFF is stored as a surrogate pair in JavaScript strings, so .length returns UTF-16 code units, not characters. A 15-character display-name limit becomes a 7-character limit for these users, and a naive .slice() for a preview truncates straight through the middle of a code point and emits a lone surrogate. That lone surrogate is what shows up later as � in your emails, or as an invalid-UTF-8 error the first time it hits a stricter downstream service.
Use [...str] or Array.from(str) when you mean characters, and Intl.Segmenter when you mean what a human would call a character (that one also handles emoji with ZWJ sequences and combining marks).
2. Your blocklist stops matching
Whitelist validation is fine — /^\w+$/u rejects 𝓪𝓭𝓶𝓲𝓷 because \w is ASCII-only. The problem is everywhere you use a blocklist:
const reserved = ['admin', 'support', 'billing'];
reserved.includes('𝗮𝗱𝗺𝗶𝗻') // false
'𝗮𝗱𝗺𝗶𝗻'.includes('admin') // false
Reserved usernames, profanity filters, spam-keyword rules, moderation regexes: all of them compare against ASCII and all of them are trivially bypassed by a copy-paste generator. This is not a theoretical attack. It is how "support" impersonation accounts get past signup on platforms that only check the literal string.
3. Search and sorting silently misbehave
'𝓯𝓪𝓷𝓬𝔶'.includes('fancy') // false
['banana', '𝓪pple', 'cherry'].sort() // ['banana', 'cherry', '𝓪pple']
The sort result is not a bug — default sort() compares code units, and U+1D4EA sorts after every ASCII letter. But it means the user who styled their name is now at the bottom of every alphabetical list in your product, and unfindable by typing their name into your search box. They will report this as "search is broken."
4. NFKD fixes most of it, and then stops
Unicode normalisation is the standard answer, and for the maths alphabets it works beautifully:
'𝓯𝓪𝓷𝓬𝔶'.normalize('NFKD') // 'fancy'
'𝗯𝗼𝗹𝗱'.normalize('NFKD') // 'bold'
'ᵗⁱⁿʸ'.normalize('NFKD') // 'tiny'
'ⓑⓤⓑⓑⓛⓔ'.normalize('NFKD') // 'bubble'
Then you hit this:
'ᴛɪɴʏ ᴛᴇxᴛ'.normalize('NFKD') // 'ᴛɪɴʏ ᴛᴇxᴛ' ← unchanged
's̶t̶r̶i̶k̶e̶'.normalize('NFKD') // 's̶t̶r̶i̶k̶e̶' ← unchanged
Two different reasons, both worth knowing.
Small caps are not decorated letters. ᴛ is U+1D1B, LATIN LETTER SMALL CAPITAL T, from the Phonetic Extensions block. Linguists needed it to write IPA. It has no compatibility decomposition to t because, as far as Unicode is concerned, it is not a t — it is its own letter that happens to look like a small one. NFKD is defined by those decomposition mappings, so there is nothing for it to do. .toUpperCase() won't touch it either.
Strikethrough and Zalgo are combining marks. s̶ is a plain ASCII s followed by U+0336 COMBINING LONG STROKE OVERLAY. The base letter was there all along; normalisation has no reason to remove a mark you deliberately added.
So the complete fold needs three passes, not one:
const SMALL_CAPS = {
'ᴀ':'a','ʙ':'b','ᴄ':'c','ᴅ':'d','ᴇ':'e','ꜰ':'f','ɢ':'g','ʜ':'h','ɪ':'i',
'ᴊ':'j','ᴋ':'k','ʟ':'l','ᴍ':'m','ɴ':'n','ᴏ':'o','ᴘ':'p','ǫ':'q','ʀ':'r',
'ꜱ':'s','ᴛ':'t','ᴜ':'u','ᴠ':'v','ᴡ':'w','ʏ':'y','ᴢ':'z',
// no x: Unicode's small capital X is unrenderable in most fonts, so
// generators leave lowercase x alone and there is nothing to fold.
};
const SMALL_CAPS_RE = new RegExp(`[${Object.keys(SMALL_CAPS).join('')}]`, 'gu');
function foldFancy(input) {
return input
.replace(SMALL_CAPS_RE, (c) => SMALL_CAPS[c]) // before NFKD: ǫ would decompose first
.normalize('NFKD') // maths alphabets, super/subscript, circled
.replace(/\p{Mn}/gu, '') // combining marks: strikethrough, underline, Zalgo
.replace(/[^\P{C}\n\t]/gu, '') // zero-width and other control characters
.normalize('NFC');
}
Results:
foldFancy('𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮') // 'fancy name'
foldFancy('ᴛɪɴʏ ᴛᴇxᴛ') // 'tiny text'
foldFancy('s̶t̶r̶i̶k̶e̶') // 'strike'
foldFancy('ⓐⓓⓜⓘⓝ') // 'admin'
foldFancy('𝗮𝗱𝗺𝗶𝗻') // 'admin'
foldFancy('ᵃᵈᵐⁱⁿ') // 'admin'
foldFancy('admin') // 'admin' ← that one had a zero-width space in it
That last line is the one I'd flag to your security reviewer. Zero-width characters are invisible in every UI you own, and they are the same bypass as the fancy letters with none of the visual tell.
Two caveats on that function. \p{Mn} strips all non-spacing marks, so foldFancy('café') returns 'cafe'. For a search key that is usually what you want. For anything you intend to display back to the user it is data loss, so keep this on the comparison path only. And the small-caps ranges cover the Latin ones; if you care about Cyrillic or Greek lookalikes you are in homoglyph-attack territory, which is a bigger problem with a real answer (Unicode TR39 and the confusables table).
5. Screen readers give up
This is the part that turns a curiosity into an accessibility issue.
Screen readers pronounce characters using their pronunciation dictionaries, which are built for the letters people actually write with. Hand them the maths alphabets and the behaviour ranges from reading the Unicode character name aloud, to spelling the word out letter by letter, to skipping the run entirely — it varies by screen reader, by version, and by the TTS voice underneath. A bio that says 𝓱𝓮𝓵𝓵𝓸 𝓲'𝓶 𝓪 𝓭𝓮𝓼𝓲𝓰𝓷𝓮𝓻 can come out as silence, or as forty seconds of character names.
Same story for search engines and for anything doing NLP on your content. The text looks like words to a sighted human and like noise to every machine that processes it.
You cannot stop users from doing this, and honestly it's their bio. What you can do is keep the folded version alongside the original, and use it for everything except display.
The pattern that actually works
Store what the user typed. Never rewrite their name for them — it's theirs, and they picked it deliberately.
Alongside it, store a folded key, and use that for the comparison paths:
// on write
await db.users.insert({
displayName: input, // '𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮' — render this
displayNameFolded: foldFancy(input) // 'fancy name' — index, search, sort, moderate on this
});
Then: uniqueness checks against the folded column, blocklists against the folded column, full-text index on the folded column, ORDER BY on the folded column, moderation on the folded column. Render the original, with the folded text as an aria-label when the field is user-facing:
<span aria-label="fancy name">𝓯𝓪𝓷𝓬𝔶 𝓷𝓪𝓶𝓮</span>
That one line gets you most of the accessibility win for free.
If you're on Postgres, the same idea lives in a generated column plus an index on it, which keeps the two from drifting. The application-level version drifts the first time someone writes to the table from a migration script.
Test data
Fixtures for this are annoying to type by hand, because you cannot type these characters — you have to generate them. I maintain tinytextgen.com partly because I needed a fast way to produce them: paste a string, get the small caps, superscript and subscript versions side by side, copy one out. The full set of styles covers the maths alphabets, circled letters and combining-mark effects, which is roughly the space you want your test suite to cover.
A reasonable fixture list: one maths-alphabet string, one small-caps string, one with combining marks, one with a zero-width space, and one plain-ASCII control. If those five pass through your signup, your search and your moderation intact, you're in decent shape.
Anything I missed? I'd be curious whether anyone has hit this in a database collation rather than in application code — that's the version I suspect is out there and under-reported.
