Convert text to NFC, NFD, NFKC or NFKD, computed entirely in your browser, so visually identical strings compare equal with no run limit.
Free · no account · nothing leaves your browser
The tool
The same visible character frequently has more than one valid byte-level representation in Unicode. This tool rewrites text into any of the four standard normalization forms, NFC, NFD, NFKC or NFKD, so that strings which are visually identical also become identical at the byte level.
Normalization runs entirely client-side, in JavaScript, within your browser. There is no upload and no server round trip, and accordingly no run limit.
How it works
One decision: which form the task requires.
Root cause
Consider é. It can be represented as a single precomposed codepoint, or as two separate codepoints, a base e followed by a combining acute accent, both rendering identically. Neither representation is incorrect. A byte-level comparison between the two, however, reports them as distinct strings.
This produces a genuinely common class of bug: two systems that each render 'é' correctly can still fail to recognize the same input entered into both, because one system encoded it as a single character and the other decomposed it into a base letter plus a mark, with no step reconciling the two as equivalent.
The four forms, defined
Unicode Standard Annex 15 defines four normalization forms, and this tool converts between all of them without restriction.
A load-bearing distinction
NFC and NFD only reorganize how a character carrying combining marks is encoded; neither alters the visual appearance of the text. NFKC and NFKD extend further, folding together characters that are visually distinct yet considered compatible variants of an underlying letter: a fi ligature, one glyph combining f and i, expands into the two separate letters, and fullwidth Latin characters, used in certain East Asian typesetting conventions, fold down to their ordinary-width equivalents.
That additional folding is genuinely lossy: NFKC and NFKD can alter the visible text, collapsing a stylistic distinction the source may have relied on deliberately. NFC or NFD is the correct choice for equality checking without altering appearance; NFKC or NFKD is correct when compatibility variants specifically need to be folded together, most commonly for search or security matching.
Consequences
A username stored under one encoding but submitted at login under the other fails to authenticate, despite both being visually identical. A search index built from mixed normalization forms fails to surface results that are, character for character visually, exactly what was queried. A deduplication process double-counts a value purely because two copies happen to use different encodings of the same accented letter.
Security-conscious systems apply compatibility normalization specifically to detect look-alike text used to disguise a domain name or a username, since visually confusable strings frequently normalize to an identical result once compatibility folding is applied.
Who it's for
Engineers debug a string comparison, a search match, or a deduplication step failing silently on text that appears identical to a human reviewer. Teams building systems that accept text from a mix of keyboards, operating systems and input methods, any of which can encode the same visible character differently, normalize on ingestion for exactly this reason.
It is also used in security review, distinguishing whether two visually similar strings are the same text in disguise, or genuinely different characters that merely resemble one another.
All answered in full, nothing to click open.
Paste it into the input field, select a form, and the normalized result is returned.
Yes. No length cap and no run limit, because processing happens on your own device rather than a metered server.
Not by this tool. Normalization runs entirely client-side. Other tools on this site that rewrite or generate text send content to a server, stated on those pages.
NFC combines a base letter and its accent into a single precomposed character wherever possible. NFD performs the reverse, decomposing a precomposed character into base plus separate marks.
NFC. It is the form most existing web text already uses, and is appropriate for consistent, comparable text without altering appearance.
NFKC performs everything NFC does, plus folds compatibility variants, such as ligatures and fullwidth characters, into their ordinary equivalents, which can alter appearance.
They likely use different normalization forms: one a single precomposed character, the other a base letter plus a separate combining mark. Normalizing both to the same form resolves the mismatch.
NFC and NFD alter only the encoding, not the appearance. NFKC and NFKD can alter appearance, since they fold ligatures and other compatibility variants.
A single character merging two letters into one glyph, such as fi. NFKC and NFKD expand it into separate letters; NFC and NFD leave it unchanged.
Latin letters rendered with wide, East Asian-style spacing, used in certain CJK typesetting conventions. NFKC and NFKD fold them to their ordinary-width equivalents.
Yes, this is the central case addressed. NFC produces the single-character form; NFD produces the base-letter-plus-mark form.
Compatibility normalization can reveal when two visually confusable strings reduce to an identical result, which is why security tooling applies it.
Yes, the layout adapts and normalization runs identically on mobile.
If the cause is mismatched normalization between indexed text and the query, yes; normalizing both to the same form resolves that specific failure.
Not currently. This is a single-document, browser-based tool.
Yes, nothing is transmitted or retained by this tool.
No, normalization reorganizes encoding without deleting anything visible. For removing accents, use the accent remover instead.
NFD performs canonical decomposition only. NFKD performs the same decomposition, plus folds compatibility variants such as ligatures into their plain form.
Those rows likely use different normalization forms of the same visible text. Normalizing incoming data consistently on ingestion prevents this.
Yes, most web content and software defaults to NFC, making it the appropriate starting point absent a specific reason for another form.
All four forms, computed locally, with no run limit and no signup.
Open the normalizer