Unicode Normalizer (NFC / NFD / NFKC / NFKD)
Text that looks identical but will not match in search, filenames that mysteriously differ — usually a Unicode normalisation mismatch. The tool reports the current form and converts to any of the four.
The four forms
NFC composes が into a single character; NFD decomposes it into か plus a combining mark. NFKC and NFKD additionally fold compatibility characters: ① → 1, ﾊﾝｶｸ → ハンカク, Ａ → A, ㍿ → 株式会社. NFKC is the usual choice before storing or comparing keys.
The macOS filename problem
macOS stores filenames in a near-NFD form, so a Japanese filename created on a Mac does not compare equal on Windows or Linux even though it looks the same. Symptoms include unsearchable names after unzipping and Git showing the same file twice. Normalising to NFC fixes it.
What normalisation destroys
NFKC and NFKD are lossy: ligatures, ½, superscripts and circled numbers cannot be recovered. Apply them to comparison keys rather than to display text.
Frequently asked questions
Why does が render as か゛?
The text is in NFD. Convert to NFC to compose it back into one character — common with text and filenames originating on macOS.
Which form should I use?
NFC for text you store or publish; NFKC for search keys and matching user input. NFD/NFKD are for specialised compatibility work.
Can I check the current form?
Yes — the tool reports whether the input is already NFC or NFD, how many combining marks it holds and how many characters NFKC would change.
Will emoji break?
No. ZWJ sequences and variation selectors are unaffected by normalisation.