The reverse of a font generator. Folds styled Unicode back to plain letters that an applicant tracking system, form field or database will accept.
The characters a font generator produces are not formatting applied to letters. They are different letters. The bold A in a styled bio is U+1D400, MATHEMATICAL BOLD CAPITAL A, a distinct character with its own code point that happens to look like a bold A.
That is what makes it work in a bio, where there is no formatting to apply, and what makes it fail everywhere something needs to read the text rather than display it. An applicant tracking system parsing a CV sees a string of mathematical symbols where a name should be, and the field comes back empty or as boxes. A search index does not match the styled form against a plain query, so the record becomes unfindable. A database column with a restricted character set rejects the insert outright. Sorting places the whole Mathematical Alphanumeric Symbols block after every ordinary letter.
Accessibility is the case that gets least attention and matters most. A screen reader announcing U+1D400 does not say A. Depending on the voice it reads a character description or skips it, so a bio styled in mathematical bold is unreadable to anyone using assistive technology. Styling a display name that way is not a neutral aesthetic choice.
The conversion starts with Unicode NFKD normalisation, Normalisation Form Compatibility Decomposition, which does most of the work by itself.
Unicode distinguishes canonical equivalence from compatibility equivalence. Canonical equivalence covers characters that are genuinely the same, such as an accented letter written as one code point or as a base letter plus a combining mark. Compatibility equivalence is looser: it covers characters that represent the same abstract letter with a different presentation. The mathematical alphanumerics are defined as compatibility variants of ASCII letters, and so are fullwidth forms, superscripts, subscripts and enclosed alphanumerics.
Because the standard already records those relationships, `String.prototype.normalize('NFKD')` folds every one of them back to plain ASCII without any lookup table. That single call handles bold, italic, script, fraktur, double-struck, monospace, fullwidth vaporwave text, and superscript and subscript digits.
The K in NFKD is the lossy part and it is deliberate: compatibility decomposition discards presentation information. That is exactly what you want here and exactly what you would not want when comparing user identifiers, where NFC is the correct form.
Two categories survive NFKD and need explicit handling.
First, combining marks. Zalgo text is ordinary letters with dozens of combining diacriticals stacked on each one, and those marks are separate code points that decomposition does not remove. It produces more of them, since it splits precomposed accented letters apart. Stripping the combining ranges after normalising is what removes the glitch effect. That is also why the accent toggle exists: an accent and a zalgo mark are the same class of character, so removing all of them flattens café to cafe, and keeping them leaves a little zalgo behind.
Second, characters that were never defined as compatibility variants. Small capitals, the upside-down alphabet and most alphabet spoofs are borrowed from the phonetic and Cyrillic blocks, and Unicode does not consider ᴀ a variant of a. It is a distinct letter used in linguistics. Those need an explicit lookup table, which this tool carries.
The third thing it removes is invisible: zero-width characters. Zero-width spaces and joiners, directional marks and the byte order mark occupy no visual width but do count against a character limit, and they routinely arrive attached to text copied from styled generators or word processors.
Before pasting a name into anything that will parse it: a job application, a form, a booking, a legal document. Before importing a CSV whose fields came from user profiles. When a search returns nothing for a record you can see. When a field rejects your text with no useful error. When you inherit copy from a designer and it carries curly quotes, en dashes and non-breaking spaces that break a code block or a URL.
It is also the honest counterpart to the rest of this site. Styled Unicode is a good idea in a bio and a bad idea in a form field, and the same tool that produces it should give you a reliable way back.
Unicode defines four normalisation forms, and choosing wrongly causes bugs that are extremely hard to see because the text looks identical on screen.
NFC composes: it prefers a single precomposed code point where one exists, so é becomes U+00E9. This is the form for storage and transmission. It is what the W3C recommends for the web, and it is what you should normalise user input to before saving it, so that two visually identical usernames cannot occupy two different rows.
NFD decomposes canonically: é becomes e plus a combining acute accent. Useful when you want to strip accents (decompose, then remove the combining range) which is how accent-insensitive search is usually built.
NFKC and NFKD add compatibility decomposition, which is the lossy step. They fold mathematical bold, fullwidth forms, superscripts and ligatures onto their plain equivalents. NFKD is what this tool uses because the goal is precisely to discard presentation.
The rule of thumb: NFC to store, NFD to strip accents, NFK* only when you deliberately want to lose the styling. Never compare identifiers across different forms, and never apply NFKC to something like a password, where discarding the distinction between two visually similar characters silently shrinks the keyspace.
Only with keep accents off. Combining marks are the same class of character whether they are a French accent or a zalgo stack, so keeping accents preserves both and removing them flattens both.
Yes. Zero-width spaces and joiners, directional marks and the byte order mark are stripped. They render as nothing but still count against character limits, and they arrive attached to copied styled text more often than people realise.
Because Unicode never defined them as compatibility variants of a Latin letter. Small capitals and the upside-down alphabet are borrowed from phonetic and Cyrillic blocks, so they need an explicit lookup rather than NFKD normalisation.
Normalisation Form Compatibility Decomposition. It folds characters that represent the same abstract letter with different presentation (mathematical bold, fullwidth, superscript) back to plain ASCII, using relationships the Unicode standard already records.
Frequently. An applicant tracking system parses text rather than displaying it, so mathematical alphanumerics arrive as unreadable symbols. Screen readers have the same problem, which is the stronger reason to keep names plain.
Broadly, yes. That one maps ASCII to styled Unicode; this maps it back. The round trip is not always exact, because several styles collapse different inputs onto the same output.
NFC, the composed form. It is the W3C recommendation for the web and it prevents two visually identical strings occupying two rows because one used a precomposed accent and the other a combining mark.
No. The fold is deliberately lossy, several distinct styles decompose to the same plain letters, so the conversion cannot be reversed. Keep a copy of the styled version if you need it.