ChatGPT Watermark Remover: Strip Invisible Characters from AI Text

"ChatGPT watermark" is a catch-all term for anything AI-generated text carries that lets a detector — human or algorithm — identify it as machine-written. There are three separate things people mean when they search for a "ChatGPT watermark remover," and they need different fixes.

1. Invisible Unicode markers (the literal watermark). Some AI outputs contain zero-width or non-standard Unicode characters that don't render on screen but survive copy-paste. The most common culprits:

• U+200B — Zero-width space
• U+200C — Zero-width non-joiner
• U+200D — Zero-width joiner
• U+2060 — Word joiner
• U+FEFF — Byte order mark / zero-width no-break space
• U+00A0 — Non-breaking space (often inserted around numbers and units)
• U+202F — Narrow no-break space
• U+180E — Mongolian vowel separator (historically zero-width)

2. Statistical / stylistic fingerprints. LLMs favor certain phrasings ("delve into", "in the ever-evolving landscape", "it's important to note that"), predictable sentence rhythm, and em-dash overuse. Detectors like GPTZero and Originality.AI look at perplexity (how predictable each token is) and burstiness (variation in sentence length). No character removal fixes this — you have to edit the prose.

3. Visible formatting tells. Curly quotes, em dashes with hair spaces around them, "smart" apostrophes, and non-standard bullet characters (•, ‣, ⁃) all get inserted by AI outputs and mark the text as pasted-from-a-chat.

A good cleanup addresses all three. SnapTextClean handles #1 and #3 in one pass; #2 needs a human edit.

Watermark removal has legitimate uses that don't involve academic fraud:

• Publishing to a CMS that treats zero-width characters as content and breaks URL slugs, meta descriptions, or search indexing.
• Feeding AI text into code, JSON, or CSV where an invisible U+200B in a field name silently breaks a parser.
• Preventing false positives in your own workflow — internal AI-drafting tools that trip your company's AI-detection filter even after a human rewrite.
• Cleaning training data for fine-tuning, where invisible tokens skew tokenization.
• Email deliverability — some spam filters flag messages containing unusual zero-width characters.
• Accessibility — screen readers occasionally announce or pause on zero-width characters, degrading the listening experience.

The remover at the top of this page is not a detector-beater and not a decoder of any secret signal. It is a deterministic character cleaner: it removes or normalizes the specific code points that AI chat output carries. Here is the complete list, with the rule that handles each one.

What it does not touch: em dashes and en dashes are left as-is (they are legitimate punctuation, and the engine has no dash rule), and nothing here changes your wording. If you want the em dashes gone, do it manually — that is an editing decision, not a cleanup.

Before / after, character-for-character. Take a typical ChatGPT paragraph. The raw copy contains, between "results" and "—", a zero-width space, and a non-breaking space before "2026":

The results[U+200B] — as expected in[U+00A0]2026 — were “clear” and didn’t[U+00AD] surprise us.

After one pass with the AI-text preset:

The results - as expected in 2026 - were "clear" and didn't surprise us.

The zero-width space, the non-breaking space and the soft hyphen are gone; the curly quotes and apostrophe are now straight ASCII. Nothing else moved. (Bracketed labels above stand in for characters that are invisible on screen — that is the whole problem with them.)

Verifying it worked. Turn on Advanced mode in the tool and open the character inspector: the before view lists U+200B, U+00A0 and U+00AD with counts, and the after view lists none. If you prefer an outside check, paste both versions into any Unicode code-point viewer.

Everything runs in your browser — the text is never uploaded, which matters when the "AI draft" is client work or an internal document. For the wider formatting cleanup beyond invisible characters, see Clean ChatGPT Text; for a full reference on hidden code points in any source, see Remove Invisible Characters.

You don't strictly need a web tool. Any of these work in a pinch.

VS Code / Sublime Text — regex find-and-replace.

Open Find & Replace, enable regex mode, and replace with an empty string:

[\u200B-\u200D\u2060\uFEFF\u180E]

Then a second pass to normalize non-breaking spaces:

[\u00A0\u202F\u2009\u200A]

Replace with a single regular space.

Microsoft Word.

Word doesn't expose zero-width characters in its normal Find dialog, but the workaround is to paste into Notepad first (Notepad strips most invisible characters via its plain-text conversion), then paste back. For non-breaking spaces, use Find and Replace with ^s to find and a regular space to replace.

Google Docs.

Edit → Find and replace → check "Match using regular expressions" → search for [\x{200B}-\x{200D}\x{FEFF}] → replace with nothing.

Command line (pipe through Python).

bash
python3 -c "import sys,re; sys.stdout.write(re.sub(r'[\u200B-\u200D\u2060\uFEFF\u180E]', '', sys.stdin.read()))" < input.txt > clean.txt

Node.js.

js
const clean = text.replace(/[\u200B-\u200D\u2060\uFEFF\u180E]/g, "")
                  .replace(/[\u00A0\u202F]/g, " ");

Notepad (Windows) and TextEdit (Mac — plain text mode).

Paste → copy → paste back. Plain-text editors drop most invisible characters during their own re-serialization. This isn't guaranteed but works for the common cases.

Which method to pick: the remover on this page for occasional cleanup, VS Code regex for repeated work in an editor you're already using, and the CLI pipe for batch processing many files. If your problem is that pasting carries fonts, colours and links along with the characters, use Paste Without Formatting instead.

Stripping invisible characters is necessary but not sufficient to pass modern AI detection. Detectors weigh several signals:

Perplexity — how predictable each next word is. GPT output has low perplexity because the model literally chose the most likely tokens. Human writing has bursts of surprising word choices.

Burstiness — variation in sentence length. AI defaults to a rhythm of medium-length sentences. Human writing mixes 3-word fragments with 40-word ramblers.

Vocabulary tells. Frequent tells that survive character cleanup: "delve", "moreover", "furthermore", "it's important to note", "in conclusion", "navigate the complexities", "in the ever-evolving landscape of", "tapestry", "leverages", "seamless", "robust", "meticulous".

Structural tells. Rigid 3-point lists, opening with a definition, always finishing with a summary paragraph, symmetric sentence structure across a paragraph.

Em-dash overuse. ChatGPT ships em dashes at ~5–10× the rate of human writing. Even after normalizing them to hyphens, the rhythm of setting off asides with dashes is a tell.

If your goal is text that reads as human-written for a specific detector, you need to actually edit: vary sentence length, cut generic transitions, add specific details only the writer would know, and let go of the perfectly balanced paragraph. Character cleanup gives you a clean surface; the editing gives you a human voice.

Different LLM providers leave slightly different residues. What we've observed in production output (as of 2026):

ChatGPT (GPT-4o, GPT-4.1, GPT-5). Heavy em-dash use, curly quotes, occasional U+00A0 around numbers and units ("5 kg", "2024"), U+2009 (thin space) around punctuation in some outputs. Some accounts and API modes show occasional U+200B insertions after headings.

Claude (Sonnet, Opus). Cleaner Unicode footprint. Straighter quotes by default. Still uses em dashes heavily. Occasionally ships U+00A0 before French-style punctuation even in English text.

Gemini (2.5 Pro, Flash). Uses Google-style curly quotes aggressively. Frequent bullet points with U+2022 (•). Sometimes leaves markdown syntax fragments () when copy-pasted from certain surfaces.

Perplexity, Copilot, Meta AI. Mostly downstream of the above models — same tells depending on which backend served the response.

Local models (Llama, Mistral, Qwen). Cleaner than commercial models on invisible characters (fewer post-processing pipelines) but heavier on markdown artifacts and repetition.

The universal cleanup — strip zero-widths, normalize spaces, straighten quotes, standardize dashes, drop stray markdown — handles all of them in one pass. Don't waste time building a model-specific pipeline unless you're processing thousands of documents from one source.

"Cleaned" isn't the same as "clean." Three quick verification methods:

1. Character count comparison. Paste before and after into any character counter. If the character count drops by 5–50 characters on a paragraph, invisible tokens were present. If it drops by hundreds, you had a serious problem.

2. Hex dump. In a terminal:

bash
echo -n "your text here" | xxd | grep -E 'e2 80 8[b-d]|ef bb bf|c2 a0'

The grep matches the UTF-8 byte sequences for U+200B–U+200D, U+FEFF, and U+00A0. No matches = clean.

3. SnapTextClean's Character Inspector. Paste text into the inspector tab. It lists every non-ASCII codepoint with its Unicode name, count, and location. If you see U+200B, U+2060, or U+FEFF, your "clean" pass missed them.

4. AI-detection sanity check. Run the cleaned text through GPTZero or Originality.AI. If the score barely moves, character cleanup wasn't your bottleneck — the prose itself needs editing (see the "won't fix" section above).

The point of verification is to catch pipeline bugs. A cleanup tool that silently missed U+2060 (word joiner) because it wasn't in its blocklist looks like it worked, but your file still triggers the detector.