Everyone knows NFC composes, NFD decomposes, and the two undo each other.
Over the 2,061 characters that actually have a canonical decomposition, NFC(NFD(c)) === c holds for 941 and fails for 1,120 — 54.34%, more than half.
Check any character: https://dev48.infy.uk/solve/day76-unicode-normalization.html
The page implements UAX #15, not a wrapper
Recursive canonical and compatibility decomposition, the canonical ordering algorithm, the derivation of Full_Composition_Exclusion, the blocked-composition rule and the Hangul arithmetic — written from the raw UCD fields rather than calling out to a library. Otherwise it would be testing the library's opinion rather than the standard.
Two ways it fails
It declines to recompose. U+0958 DEVANAGARI LETTER QA is one assigned character. NFD turns it into two, and NFC will never put it back — it is on the composition-exclusion list, so the round trip is lossy by design.
Or it hands back a different character. For 1,035 of the failures NFC does not merely decline:
U+212B ANGSTROM SIGN
NFD -> U+0041 U+030A
NFC -> U+00C5 LATIN CAPITAL LETTER A WITH RING ABOVE
Same rendering. Different code point. Your string went in as one character and came out as another, and every equality check downstream now depends on which normalisation ran last.
What to do with that
Normalise once, at the boundary, and compare normalised forms — never assume a round trip is identity. If you are storing a key, store the normalised form; if you are comparing user input to it, normalise the input the same way. The failure mode is not corruption, it is two spellings of the same text that never compare equal.
17,581 verifier assertions, 0 failures. Vanilla JavaScript, one file, no build step.
