ChatGPT Watermark Remover — Strip Invisible Characters from Copied Text

What people mean by a ChatGPT watermark

The phrase gets used for two very different things. The first is a hypothetical signal embedded at the model level, inside the words themselves, which no browser tool could read or alter. The second is the one you can actually do something about: the layer of invisible characters and formatting residue that a chat interface attaches to the text you copy.

This tool deals only with the second. It has no access to anything a model may or may not have produced, and it makes no claim about it either way. What it can do is show you precisely which invisible characters are sitting in your clipboard right now, and take them out.

What this tool removes

Zero-width spaces, non-joiners and joiners that hide between characters. The byte order mark. Directional marks, embeddings and isolates that control how a line is ordered. Soft hyphens that only appear at a line break. Non-breaking, figure and narrow non-breaking spaces that masquerade as ordinary spaces.

It also tightens formatting residue: carriage returns left over from Windows line endings, runs of two or more spaces reduced to one, and three or more consecutive line breaks reduced to two. Every one of these changes is counted in the report, so nothing happens quietly.

Check first, then clean

You do not have to take the tool's word for any of this. The report panel lists each character type that was found, its Unicode code point, and how many times it appeared. Paste the same text into the detector page if you want the report on its own, without producing a cleaned copy.

If the report comes back empty, your text was already free of the characters in the table. That is a useful answer too — it means whatever you were seeing in your editor has a different cause, and you can stop looking here.

About provenance signals

Text carries more than its characters. Documents have metadata, files have authorship fields, and platforms log where content came from. This tool touches none of that. It operates on one thing only: the sequence of characters you paste into the box.

It does not read, detect, alter or comment on any signal a model or platform may attach to text, and it makes no claim about how a piece of writing will be judged by anyone. It removes invisible characters. That is the whole of what it does.

Zero-width characters and what they actually are

Zero-width characters are real Unicode code points that render as nothing. They take up space in a file and in a database column, they affect how text is indexed and compared by software, and they are completely invisible to the human eye in any normal reading context. The most common ones you will encounter in copied text are the zero-width space (U+200B), the zero-width non-joiner (U+200C), and the zero-width joiner (U+200D). A fourth, the word joiner (U+2060), is sometimes used to suppress line breaks at a specific position.

These characters have legitimate uses. Software that handles Arabic, Hebrew, or other scripts with complex joining rules relies on non-joiners and joiners to control glyph shaping. Multilingual typesetting uses them to mark optional break points without introducing a visible space. The problem is not that the characters exist — it is that they arrive in plain prose where they have no typographic purpose, and most editors have no way to show them. You type around them, your spell checker ignores them, and your database stores them faithfully.

The claim that platforms deliberately insert these characters as tracking markers appears regularly in online forums, and it is worth separating what is documented from what is speculated. What is documented: rendering engines and clipboard handlers insert zero-width characters as a side-effect of how they handle text layout. What is speculated: that any particular combination of these characters encodes a unique identifier traceable to a session or user. The second claim would require the encoder and the detector to share a key, which no public tool has demonstrated. This tool makes no judgment either way. It removes the characters because they are noise in most plain-text contexts, not because it has any evidence about what put them there.

How to check your text manually before cleaning

You do not need to trust any tool to tell you whether invisible characters are present. There are a few ways to check directly. The most accessible is to paste your text into a plain-text editor that can show non-printing characters — most code editors have this option under a name like 'show invisibles' or 'render whitespace'. Enable it and look for dots, arrows, or small glyphs between letters where there should be nothing.

A second method uses the browser console. Open the developer tools in any browser, click the Console tab, and run this one-liner after pasting your text into a variable: paste your text into a string literal, then call .split('').map(c => c.codePointAt(0).toString(16)).join(' ') on it. The output is a hex list of every code point. Any value in the zero-width range — 200b, 200c, 200d, 200e, 200f, 202a through 202e, feff — is an invisible character.

A third method is a regex search in a capable editor. In VS Code, enable the regex toggle in the find bar and search for [\u200b-\u200f\u202a-\u202e\ufeff]. Any match highlights an invisible character in place. This approach shows you exactly where each one sits in the text, which is more informative than a count.

After you clean your text with this tool, repeating any of these checks should return nothing. If something still shows up, the report panel will have caught it too — compare the two to make sure they agree. If they disagree, the editor's raw view is authoritative.

Using cleaned text correctly afterward

Removing invisible characters does not change the meaning or structure of your text, but it does change how software handles it. A string comparison that was failing because two copies of the same word contained different zero-width characters will now succeed. A search index that was splitting a phrase at a zero-width space will now index it as a single token. A database column with a unique constraint that was rejecting a duplicate because the duplicate had a byte order mark the original did not will now correctly detect the collision.

If you are moving text into a content management system, clean it before you paste, not after. Most CMSes escape HTML on input, which means a zero-width space stored at write time becomes an encoded entity at read time, and the entity is harder to strip than the original character. The same applies to markdown — a zero-width character between two asterisks can break bold syntax in ways that look fine in the source but render wrong in the output.

For text going into code — variable names extracted from a document, API keys copied from a dashboard, configuration values from a PDF — invisible characters are a common source of authentication failures and parse errors that produce no useful error message. The parser sees a character that looks right but has the wrong code point, rejects it, and reports a generic syntax error. Pasting through this tool before using any string in code is a simple habit that catches this class of problem before it reaches a terminal.

One thing this tool does not do: it does not alter line endings to match a target platform, and it does not change encoding. It normalizes carriage-return-plus-line-feed sequences to plain line feeds, because those are overwhelmingly noise in web contexts, but it does not otherwise rewrite the structure of your text. If you need to convert encoding or normalize Unicode forms — NFC versus NFD — that is a separate step this tool does not perform.

A final note on workflow: cleaning text is most useful as a one-time step, not a repeated ritual. If you build a habit of pasting through a cleaning tool before any text goes somewhere that matters — a CMS, a codebase, an email template, a spreadsheet column used as a key — you catch invisible character problems before they propagate. Once a zero-width character is in a database, it tends to replicate: every export, every copy, every downstream system gets it. The cost of removing it after the fact is much higher than the cost of removing it before the first write. This tool is fast enough that treating it as a default paste step adds essentially no friction to a normal writing workflow.