Will encoding cleaned text as UTF-16LE automatically add a BOM?

Measured inputs and outputs

These are locally constructed test strings, not evidence that Claude inserts these characters. We executed the saved homepage script snapshot with a minimal DOM harness and compared exact strings. The invisible-checkbox state and dash mode appear in each row. The observations below test this page's specific question. Destination observations run independently on the exact input and cleaned strings in the recorded Node runtime. We make no detector-score or statistical-watermark removal claim.

The encoder writes bytes under a named contract

The marked ASCII source produces UTF-16LE hex 41000b204200. After cleanup it produces 41004200, four bytes representing A and B as little-endian code units. Neither branch starts with fffe. The ordinary AB reference has the same four-byte result with no deletion. We also retain UTF-8 hex beside it, where AB is only 4142, to make the export encoding visible. The cleaner returns a JavaScript string; selecting UTF-16LE happens later in the observer. A successful cleanup therefore does not by itself specify the bytes or character encoding of a file a separate application might create.

An explicit leading character controls the marker

The leading-U+FEFF source produces fffe41004200 and the observer marks its first two bytes as matching the UTF-16LE BOM spelling. After the homepage removes U+FEFF, the encoder returns 41004200 and the prefix check becomes false. This does not mean the encoder detected a file and removed its metadata: it encoded whichever string it received. Our astral emoji control produces 3dd800de and round-trips through the same named Buffer encoding unchanged. That row also shows why a supplementary character occupies a surrogate pair in this output rather than one two-byte unit. No automatic prefix is added there either.

Add a file marker only when the format calls for it

Check the destination’s encoding declaration and BOM requirements before export. If the format requires a marker, construct its byte prefix at the file-writing stage under that contract rather than relying on an accidental U+FEFF in pasted text. If the format forbids one, do not add it merely because the output encoding is UTF-16LE. Keep the original string and inspect generated bytes when investigating interoperability. Our source fixture with a leading marker illustrates the difference between text cleanup and byte-level file packaging. We do not save a user document or claim the homepage has an encoding selector or download feature.

Output encoding differs from the earlier input diagnosis

The existing UTF-16 guide starts with incoming bytes and demonstrates damage from a wrong decoder. This page starts with intact strings and measures the exact bytes generated by an explicitly chosen encoder. The round-trip column uses the same Buffer encoding, without TextDecoder’s BOM handling, so it intentionally retains an explicit leading character before cleanup. We do not test big-endian output, a spreadsheet exporter, a browser file picker or automatic encoding detection. Four synthetic inputs establish the recorded byte and prefix behavior only. These results provide no evidence about the origin of the strings, hidden author information or removal of a statistical watermark.

Reproduce this test

Save reproduce.cjs and tested-app.js in the same folder. Run the command below with Node.js. The harness prints its runtime, script SHA-256 and every measured row. Compare those rows with the original record. Using a newer script or runtime creates a new experiment; retain the version information with your rerun.

node reproduce.cjs