Unicode normalise

All four that Unicode defines: NFC, NFD, NFKC and NFKD, through the form option, which defaults to NFC. The work is done by the browser's own String normalize, so the result matches what any other conforming implementation would produce for the same form. There are no other settings, and no partial or custom mode.

Composition. NFC prefers a single precomposed character, so e with an acute accent is one code point. NFD decomposes it into a plain e followed by a combining acute, so the same visible text takes two code points. Both render identically and both compare unequal as raw strings, which is why filenames and identifiers that came from different systems often need one pass through here before they match.

When you want compatibility characters folded away. The K forms also replace characters that are formatting variants of something else: a full-width Latin letter becomes an ordinary one, a superscript two becomes a digit 2, a ligature becomes its separate letters, and a non-breaking space becomes a normal space. That is useful for search keys and identifiers, and lossy for anything where the original presentation matters.

Because your text was already in that form, or the change is one you cannot see. Most text produced on macOS or Linux and most web content is already NFC, so a normalise to NFC is a no-op. Run Unicode inspector on both versions to see the code points, or run the byte-level diff tool; a change that alters no visible glyph still changes the byte count.

The K forms can. NFKC and NFKD discard the distinction between a character and its compatibility variant, so you cannot get the full-width or superscript form back afterwards. NFC and NFD are round-trippable in the sense that either can be converted to the other. Keep your original file if there is any chance you will need the distinction later.