Normalize Unicode to NFKD

Worked example

NFKD applies compatibility decomposition without recomposition, exposing base characters and combining marks. Convert locally in your browser. For example, entering "Ｈｅｌｌｏ ①" produces "Hello 1". Compare both sides character by character; the visible spelling can hide different bytes or combining marks. Choose NFKD to expose compatibility components without recomposition. This is useful for diagnosis but can remove distinctions from the original typography.

How the representation works

Unicode normalization defines four forms. NFC and NFD are canonical: they preserve canonical equivalence while composing or decomposing where defined. NFKC and NFKD also apply compatibility mappings, such as converting fullwidth Latin letters or circled numbers to ordinary forms; these can discard distinctions that matter in some contexts. C means recomposition and D means decomposition. A normalized result may look identical to the source while its code point sequence changes. Normalization is useful before certain exact comparisons and search indexes, but the chosen form must be consistent throughout the system. It is not a universal security filter or language transliterator. NFKD applies compatibility decomposition without recomposition, exposing base characters and combining marks.

A text transformation has a direction. First identify whether your source is readable Unicode text, a list of bytes, code points or an already encoded string. Paste one short value whose meaning you know, inspect the result and only then process a larger input. Keep a copy of the source. An encoded sequence can be reversible while still revealing every original byte to anyone who knows the format; encoding alone is not a privacy measure. Processing runs in this browser, so the converter does not send your pasted content to a conversion server. The result still becomes sensitive if you copy it into a shared document, issue tracker or URL.

Limits and reliable use

Normalization does not translate language or remove every visual confusable. Compatibility forms can intentionally change text distinctions. Use the exact alphabet, byte encoding and normalization form required by the receiving system. Similar looking formats are not automatically compatible. A decoded string can contain markup or control characters and must be treated as untrusted input by the next application. A valid conversion also does not prove that the data is authorized, safe or semantically correct. Try a round trip when the operation is intended to be reversible, and compare Unicode code points or UTF-8 bytes if two strings look equal but fail an exact comparison. For records that will be stored or signed, document the transformation as part of the data contract rather than relying on a visual preview.