A ChatGPT watermark remover that counts

The term watermark is doing a lot of work in this search result, and it is worth separating two things it gets used for. One is a statistical mark built into which tokens a model chooses, which would live in the word selection itself. The other is hidden Unicode residue in the clipboard text. This tool addresses the second and is silent on the first, because a character scanner cannot see token statistics and no amount of interface copy changes that.

What it does, concretely: it matches fourteen codepoints in the input, reports each occurrence with its codepoint and position, and on request deletes eleven of them and substitutes an ordinary space for the other three. Every other byte in the input is returned unchanged.

The work happens in the browser. No request leaves the page, so there is no account, no rate limit, no length ceiling and nothing retained. That is a consequence of the architecture rather than a policy, and it is verifiable from a network panel in about four seconds.

A page that advertises a number should be able to print the list. Here is ours, grouped by the job each character was designed to do.

Zero-width family

U+200B space, U+200C non-joiner, U+200D joiner, U+2060 word joiner. Width zero by design, used to control joining and line breaking. Deleted.

U+FEFF byte-order mark

An encoding signal that is legitimate only at the head of a stream. Mid-document it is a parser hazard. Deleted.

U+00AD soft hyphen

A conditional hyphenation point. Invisible until the line wraps on it, at which point a hyphen appears in a word that never had one. Deleted.

Space look-alikes

U+00A0 no-break space, U+202F narrow no-break space, U+200A hair space. Visually a space, different codepoint. Substituted with U+0020 rather than deleted, because the gap is semantically real.

Directional controls

U+202A and U+202B embeddings, U+202C pop, U+202D and U+202E overrides. Bidirectional layout machinery. Deleted.

The order matters, because the diagnostic value is lost once the text is retyped or reformatted.

Step 1

Paste the original clipboard content. Any intermediate step that re-renders the text, including a plain-text editor with paste cleaning on, can remove the evidence before the scan sees it.

Step 2

Scan. The report gives you codepoint and position per occurrence, which is enough to reason about where the text has been.

Step 3

Apply the removal and copy. The output differs from the input only at the reported positions.

Tools ranking for this term advertise 34 characters and 104 characters. The numbers diverge because the category is not fixed, and the padding is visible once you read the lists.

One published set counts the em dash and the em space among its invisible characters. Neither is invisible: both render. Another advertises 104 while conceding in its own copy that 28 of them are completely invisible, which means three quarters of the headline number are characters you can see. A third names codepoints we do not handle, including the Mongolian vowel separator U+180E and the directional marks U+200E, U+200F and U+061C.

Fourteen is the number here because fourteen is the length of the set the code iterates. Check any published count against the tool's own list, including this one.

Four limits, worth knowing before you rely on a result. First, absence of a finding is weak evidence. Any normalising step between the model and this page, a plain-text paste, a Markdown round trip, a form field with input sanitising, strips these characters incidentally. A clean scan is consistent with text that was never touched by a model and with text that was.

Second, presence is equally weak in the other direction. PDF exports, word processors, translation memory tools and rich-text editors all emit the same codepoints, and have done for decades. The characters are evidence of a rendering pipeline, not of authorship.

Third, the scope is exactly the fourteen listed. Variation selectors U+FE00 to U+FE0F, the invisible math operators U+2061 to U+2064 and the directional isolates U+2066 to U+2069 are untouched, as are all visible characters including em dashes, en dashes and smart quotes.

Fourth, nothing here predicts what an AI detector will say. Detectors model word choice, burstiness and sentence structure. Removing a zero-width space changes none of those, and any page that implies otherwise is selling a result it cannot deliver.

The damage is always the same shape: a string that looks equal to another string is not equal to it. That breaks exact-match search, join keys in a data load, deduplication, cache keys and URL slugs. The symptom is a null result rather than an error, which is why these take so long to find.

In source code, a zero-width character inside an identifier produces a parse failure the editor gives no sign of. In publishing, a byte-order mark in the body renders as a stray glyph or fails a validator.

The security case is narrower but real. U+202D and U+202E override the display direction of the characters that follow, so a filename or a link can be rendered to read differently from what it resolves to. Separately, invisible characters are a documented carrier for instructions aimed at a language model rather than a human reader. Sanitising text before it enters a system that acts on it is defensible on that basis alone.

Editorial teams treating it as a pre-publication step. Engineers who have lost an afternoon to a string comparison that should have succeeded. Data teams cleaning text columns before a load, where a silent failure means a wrong number in a report rather than a crash.

The manual equivalent is a Unicode character viewer, or a regex search for the codepoints in an editor that supports them. This page is faster and enumerates its own scope.