CLAUDE WATERMARK REMOVER · PRACTICAL TEST
Will cleaning normalize CRLF, LF or Unicode line separators?
The cleaning callback preserves the tested CRLF, LF, CR, U+2028 and U+2029 sequences. It only deletes the inserted U+200B; browser text fields and export steps are separate boundaries.
Open the Claude text cleaner · Full measured data
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. Invisible removal is enabled; the dash mode appears in each row. The observations below test this page's specific question. We make no detector-score or statistical-watermark removal claim.
| Fixture and mode | Input string and code points | Output and cleaner status | Observed before / after |
|---|---|---|---|
| Windows CRLF direct string / keep | "A\r\nB"U+0041 U+200B U+000D U+000A U+0042 | "A\r\nB"Removed 1 invisible character | {"crlf":1,"cr":1,"lf":1,"ls":0,"ps":0}{"crlf":1,"cr":1,"lf":1,"ls":0,"ps":0} |
| LF lines direct string / keep | "A\nB"U+0041 U+200B U+000A U+0042 | "A\nB"Removed 1 invisible character | {"crlf":0,"cr":0,"lf":1,"ls":0,"ps":0}{"crlf":0,"cr":0,"lf":1,"ls":0,"ps":0} |
| CR lines direct string / keep | "A\rB"U+0041 U+200B U+000D U+0042 | "A\rB"Removed 1 invisible character | {"crlf":0,"cr":1,"lf":0,"ls":0,"ps":0}{"crlf":0,"cr":1,"lf":0,"ls":0,"ps":0} |
| Unicode separators direct string / keep | "A
B
C"U+0041 U+200B U+2028 U+0042 U+2029 U+0043 | "A
B
C"Removed 1 invisible character | {"crlf":0,"cr":0,"lf":0,"ls":1,"ps":1}{"crlf":0,"cr":0,"lf":0,"ls":1,"ps":1} |
Count line separators independently
Each fixture contains one removable U+200B before its first separator. The callback deletes that character while retaining the original separator sequence. Our observer reports CRLF pairs as well as total CR and LF counts, preventing a Windows pair from being mistaken for two independent record boundaries. The Unicode fixture retains one line separator and one paragraph separator. Full escaped strings in the data allow exact comparison beyond the aggregate counts.
The harness does not emulate a textarea
We run the actual callback against a minimal DOM whose value property is a plain JavaScript string. Real browser textarea values can normalize line breaks before the callback reads them. Therefore these results establish only the behavior of the filtering callback on supplied strings. They do not promise byte-preserving file upload, clipboard round trips or downloaded files. ECMAScript identifies its line terminator characters; application and file-format rules must be checked separately.
Track every stage of a line-ending problem
Save original bytes and identify the file encoding and newline convention. Capture the input field value before cleaning, then capture output before export. Compare those records to locate the first changed boundary. For a source-control or import requirement, use a dedicated line-ending conversion intentionally and record it as a separate action. The homepage has no newline-conversion setting. A successful character-removal status cannot certify that every browser or export operation retained the original newline bytes.
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.cjsReference and next check
ECMAScript lexical grammar provides the relevant primary definition. The table and fixture analysis are original measurements. For broader inspection, use our Unicode inspector. Read the scope distinction before interpreting cleanup as a watermark result.