Free · 100% LocalDetect and remove invisible Unicode watermarks hidden in AI-generated text — zero-width spaces, BOM, direction marks and tag characters. Everything runs in your browser: your text is never uploaded to any server.
A ChatGPT watermark is not a logo stamped across your text. In practice, the phrase describes invisible Unicode characters — zero-width spaces, byte order marks, direction marks and Unicode tag characters — that can end up inside text copied out of a chat interface. You cannot see them on screen and they do not change how a sentence reads, but they survive a copy-and-paste into most editors and they are easy to find the moment something inspects the raw characters instead of the rendered text.
That distinction matters, because invisible characters are not automatically harmless. A run of them can carry information: assign one invisible character to binary 0 and another to 1, and a paragraph can hold a payload no reader would notice. Two strings can look identical on screen and still be different files. This is why invisible characters work as both a detection signal and a way to mark a block of text — and why their presence in AI-written text has been discussed as a form of watermarking.
The most common invisible characters are the zero-width family: zero-width space (U+200B), zero-width non-joiner (U+200C) and zero-width joiner (U+200D). All three occupy no horizontal space, so text that contains them and text that does not look exactly the same on screen.
They are not inherently broken. Zero-width joiners are required for many emoji sequences and for correct rendering in some scripts, and zero-width spaces appear in professional typesetting where a line is allowed to break. The problem is when they show up somewhere nobody asked for them — in the middle of a plain sentence, or hundreds of them scattered through one paste. That is when the symptoms appear: your word count tool disagrees with the editor, find-and-replace silently matches nothing, a query returns empty because one extra character sits inside the string, or a compiler reports an invalid character on a line that appears to be blank.
A byte order mark (U+FEFF) at the very start of a file is legitimate — it tells software how to read the byte order. The same code point appearing later in a document is a zero-width no-break space, and there is rarely any reason for it to be there. A stray BOM in the middle of a paragraph or inside a JSON string is a classic source of "why does this not work" bugs.
Other invisible marks are worth knowing by name. LEFT-TO-RIGHT MARK (U+200E) and RIGHT-TO-LEFT MARK (U+200F), together with the embedding and override controls (U+202A–U+202E), steer how bidirectional text is displayed. The soft hyphen (U+00AD) is a discretionary break you cannot see until the line actually wraps. Variation selectors (U+FE00–U+FE0F) change how the preceding character is drawn. And a small group of characters renders as blank space, including the Hangul fillers (U+3164, U+FFA0) and the ideographic space (U+3000) — genuinely useful in CJK typesetting, but indistinguishable from an ordinary space in the middle of a Latin sentence.
The tag character block (U+E0000–U+E007F) is the odd one out. The range was defined so that language tags could travel alongside text, it has no visible glyph at all, and it is deprecated for most modern use. Copied into ordinary prose it accomplishes nothing useful, and everything it does is invisible. Because the range is narrow and its legitimate uses are rare, it is one of the safest things to strip from pasted text: nothing renders differently afterwards.
This tool does the whole job inside your browser. Nothing is uploaded, and it keeps working after you disconnect from the network.
If you want to see the whole workflow before pasting anything you care about, press Load Demo. It inserts a sample paragraph that contains hidden characters, so the red marks, the detection report and the cleaned output all have something to show.
The list below covers the invisible characters this tool detects and cleans. The "typical effect" column describes what happens when they end up somewhere they do not belong.
| Character | Code point | Typical effect |
|---|---|---|
| Zero-width space | U+200B | No width; allows a line break mid-word |
| Zero-width non-joiner | U+200C | Blocks joining behaviour in scripts that use it |
| Zero-width joiner | U+200D | Joins characters; required in many emoji sequences |
| Byte order mark / zero-width no-break space | U+FEFF | Legitimate at file start, invisible junk mid-text |
| Left-to-right and right-to-left marks | U+200E, U+200F | Direction hints that survive copy and paste |
| Bidirectional embedding and override | U+202A–U+202E | Reorders how surrounding text displays |
| Soft hyphen | U+00AD | Discretionary hyphen, visible only at a line break |
| Variation selectors | U+FE00–U+FE0F | Change the glyph used for the preceding character |
| Unicode tag characters | U+E0000–U+E007F | No glyph at all; deprecated range |
| Hangul fillers | U+3164, U+FFA0 | Render as blank space |
| Ideographic space | U+3000 | Full-width space, standard in CJK text |
Because these characters have no visual form, the only reliable way to know whether a text contains them is to inspect it character by character. That is what the scan above does, and it is why the preview shows them as explicit red tags instead of trying to render them.
The public picture is simpler than the headlines suggest. Invisible characters do appear in text that comes out of chat interfaces, they are detectable, and there is an active public discussion about using that kind of marker to identify or trace machine-written text. What has not been publicly confirmed is a specific scheme — which characters, how they would be assigned, or what they would encode. Claims about a particular watermark algorithm deserve caution.
That uncertainty is exactly why a cleaner is useful. If invisible characters are present, you can see them, count them by type, and remove them. If they are not, the scan returns zero and you have lost a few seconds. Either way you end up with plain text that behaves predictably in an editor, a code file, a spreadsheet or a database.
It is the informal name for invisible Unicode characters embedded in AI-generated text — zero-width spaces, zero-width joiners, byte order marks, direction controls or Unicode tag characters. Readers cannot see them, but software can detect them, count them, and in some cases use them to trace where a piece of text came from.
Yes. It is free to use, needs no account or sign-up, and has no limit on how many times you run it. There is no paywall and no watermark of our own added to your output.
No. The detection and cleaning both run in your browser. Your text never leaves your device, which is also why the tool keeps working when you are offline.
Yes. The scan works at the character level, so it does not matter which model produced the text. Any invisible Unicode characters it finds are reported and removed the same way, whether the text came from a chat interface, a document export or a plain copy-and-paste from somewhere else.
They can do both. In code, a hidden character inside a string literal produces errors that are hard to spot because the line looks clean. In writing, word count and character count tools may disagree with each other, and search-and-replace can fail to match text you can see on screen.
Usually, yes. Invisible characters travel with the text through normal copy and paste, which is precisely what makes them useful as a marker and annoying in a document. Stripping them is a deliberate step, not something that happens by accident.
Yes. Once the page has loaded, everything runs locally in your browser, so you can disconnect and still detect and clean text.
Zero-width space, zero-width non-joiner and zero-width joiner (U+200B, U+200C, U+200D), the byte order mark (U+FEFF), bidirectional marks and controls (U+200E, U+200F, U+202A–U+202E), the soft hyphen (U+00AD), variation selectors (U+FE00–U+FE0F), Unicode tag characters (U+E0000–U+E007F), invisible space variants such as the Hangul fillers (U+3164, U+FFA0) and the ideographic space (U+3000). The detection report breaks the result down by type.
Long dashes — U+2014, U+2015, U+2E3A and U+2E3B — show up often in AI-written text and are perfectly visible, so they are not watermark characters. Some people want them converted to a plain hyphen, some want them deleted, some want them left alone. The cleaning options let you choose, and the default is to leave them untouched.
This tool performs character-level text cleanup, which is ordinary text processing. Nothing here is legal advice, and if you are using AI-generated text in a context with specific rules — academic, contractual or commercial — check the terms that apply to you rather than relying on a tool description.