Does removing invisible characters repair an unpaired surrogate?

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 marker disappears while malformed text remains

Our first source contains A, U+200B, a lone high surrogate and B. Cleanup deletes the selected marker, but isWellFormed still returns false on the resulting string. Calling toWellFormed independently produces A, U+FFFD and B and its well-formedness check returns true. The observer records both source and repaired lengths: replacement keeps the code-unit length of the particular malformed source, while deletion separately reduces it. A shorter string therefore cannot be treated as proof that the malformed part was fixed. The saved JSON escapes the surrogate so a reviewer can inspect the exact data without relying on how a font renders it.

Three controls explain what a success means

The lone low-surrogate control also becomes U+FFFD only in the explicit repair branch. The valid emoji pair remains intact and is well formed before and after both operations. An existing U+FFFD control is also well formed and remains unchanged. These results show why well formed does not mean original text recovered: the replacement control and repaired malformed controls converge on the same visible sequence. The observer retains the unrepaired source to preserve the distinction. We do not infer which character was intended at the malformed position, and no replacement is silently applied by the homepage.

Choose rejection or replacement deliberately

Before passing text to an API requiring well-formed Unicode, check the string at the relevant boundary. Decide whether malformed input should be rejected with its original preserved or deliberately replaced under an explicit loss policy. If replacement is acceptable, keep diagnostics that identify the affected positions rather than presenting U+FFFD as recovered content. Our earlier TextEncoder experiment observes replacement while generating bytes; here the repair operation returns another JavaScript string before any byte encoding occurs. That distinction matters when validating a working copy or explaining why a later encoder no longer reports an apparent problem.

Well-formedness does not validate content

The experiment uses four locally constructed strings and the supported methods in the recorded Node runtime. It does not test browser paste normalization, filesystem reads, all Unicode noncharacters or a destination protocol. A well-formed string may still contain unwanted invisible characters, misspellings or invalid application data. Likewise the cleaner can perform a correct selected deletion on a string that remains ill formed. Run the downloaded harness to inspect those separate outcomes. These records are not sampled Claude messages, and neither toWellFormed nor a successful cleanup provides evidence about a statistical watermark, an author or the original bytes of an already damaged document.

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