Text & code / MULTIVERTO

Normalize Unicode to NFKC

NFKC applies compatibility decomposition followed by recomposition; typographic distinctions can disappear. Convert locally in your browser.

Live converterYour input stays in this browser. No text is uploaded for conversion.
The file stays in your browser.
Chain tools

Apply each text tool to the previous result.

01 / Guide

How it works

NFKC applies compatibility decomposition followed by recomposition; typographic distinctions can disappear.

Good to know

Normalization does not translate language or remove every visual confusable. Compatibility forms can intentionally change text distinctions.

02 / Example

Example

Your inputHello ①
ResultHello 1

03 / Guide

Normalize Unicode to NFKC — How it works

Worked example

NFKC applies compatibility decomposition followed by recomposition; typographic distinctions can disappear. Convert locally in your browser. For example, entering "Hello ①" produces "Hello 1". Compare both sides character by character; the visible spelling can hide different bytes or combining marks. Choose NFKC only when the receiving rule accepts compatibility folding. Fullwidth letters and circled numbers can become ordinary characters, and the change may not be reversible.

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. NFKC applies compatibility decomposition followed by recomposition; typographic distinctions can disappear.

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.

How this conversion transforms the input
Unicode text
UTF-8 bytes
NFKC · Normalized Unicode text