Zerowidth CleanerAll measured guides

CLAUDE WATERMARK REMOVER · PRACTICAL TEST

Does the text before @ identify a URL hostname?

No in our fixtures. The URL parser separates username and password from the hostname after @. Deleting U+200B inside the username changes userinfo while the host stays example.com.

Tested October 9, 2026 · v24.19.0 · 4 measured runs

Open the Claude text cleaner · Full measured data

Code-point comparison for Marked username

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.

Before and after observations; full code points and strings are in the JSON download.
Fixture and modeInput string and code pointsOutput and cleaner statusObserved before / after
Marked username
direct string / keep / invisible true
"https://u​ser:demo@example.com/x"
U+0068 U+0074 U+0074 U+0070 U+0073 U+003A U+002F U+002F U+0075 U+200B U+0073 U+0065 U+0072 U+003A U+0064 U+0065 U+006D U+006F U+00 …
"https://user:demo@example.com/x"
Removed 1 invisible character
{"username":"u%E2%80%8Bser","password":"demo","hostname":"example.com","pathname":"/x"}
{"username":"user","password":"demo","hostname":"example.com","pathname":"/x"}
Multiple at signs
direct string / keep / invisible true
"https://user@label@example.com/x"
U+0068 U+0074 U+0074 U+0070 U+0073 U+003A U+002F U+002F U+0075 U+0073 U+0065 U+0072 U+0040 U+006C U+0061 U+0062 U+0065 U+006C U+00 …
"https://user@label@example.com/x"
No selected invisible characters found
{"username":"user%40label","password":"","hostname":"example.com","pathname":"/x"}
{"username":"user%40label","password":"","hostname":"example.com","pathname":"/x"}
Encoded at in user
direct string / keep / invisible true
"https://user%40label@example.com/x"
U+0068 U+0074 U+0074 U+0070 U+0073 U+003A U+002F U+002F U+0075 U+0073 U+0065 U+0072 U+0025 U+0034 U+0030 U+006C U+0061 U+0062 U+00 …
"https://user%40label@example.com/x"
No selected invisible characters found
{"username":"user%40label","password":"","hostname":"example.com","pathname":"/x"}
{"username":"user%40label","password":"","hostname":"example.com","pathname":"/x"}
No userinfo
direct string / keep / invisible true
"https://example.com/x"
U+0068 U+0074 U+0074 U+0070 U+0073 U+003A U+002F U+002F U+0065 U+0078 U+0061 U+006D U+0070 U+006C U+0065 U+002E U+0063 U+006F U+00 …
"https://example.com/x"
No selected invisible characters found
{"username":"","password":"","hostname":"example.com","pathname":"/x"}
{"username":"","password":"","hostname":"example.com","pathname":"/x"}

Userinfo is distinct from the host

All four strings are authored fixtures with no real credentials. The first parser observation returns an encoded marker within the username and example.com as the hostname. Cleanup removes U+200B and the username becomes user, while the hostname stays unchanged. The multiple-at-sign row serializes the earlier at sign as username data; the final delimiter separates the host. The encoded-at row already represents that data explicitly and remains unchanged. The plain URL has empty username and password properties. Recording each component prevents a visible prefix from being mistaken for the host that construction actually selects.

No authentication was attempted

The observer only creates URL objects. The string demo is a synthetic label, not an account secret, and nothing is sent to a server. We do not measure browser handling of credentialed links, HTTP authentication, password managers or phishing detection. This differs from our hostname experiment because the disputed text is outside the hostname component. The cleaner edits selected code points across the input without understanding component boundaries. WHATWG supplies the relevant syntax, but accepting a URL with userinfo says nothing about a login, ownership or the appropriateness of embedding credentials in a link.

Inspect components without publishing secrets

For a suspicious link, identify its actual host with the destination parser and keep any private userinfo out of screenshots or shared logs. If an accidental character belongs to an identifier, verify the intended spelling at its source before editing. Avoid assessing a host from the longest visible domain-like prefix. Our reproduction downloads use only public reserved example domains and dummy labels, so they can be shared without private data. The measured distinction is structural parsing of these strings; it does not determine whether an arbitrary link is safe or whether a service accepts URL userinfo.

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

Reference and next check

WHATWG URL Standard 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.