Invisible character detector

GPTCleanup Pro's invisible character detector reads a block of text and reports the zero-width and non-printing Unicode characters sitting inside it, each one named and located, rather than a vague warning about hidden watermarks. It's built for the question people type into search: why does my text have hidden characters. The answer is a list of findings, not an accusation.

It's a server tool: text is sent to our AI server to be scanned, and the result returns to the page. You get 5 free checks in any rolling 24 hours, no account required.

This page treats a finding as evidence to read carefully, not proof of anything. Hidden characters are common in text copied out of chat interfaces, word processors and PDFs alike, for reasons mostly unrelated to AI, and the sections below explain why plainly rather than trading on the ambiguity.

One round trip to the server, then a specific list of findings. Nothing to configure beforehand, no particular format required.

Step 1

Paste the sample, ideally using the source's own copy function, since that's the version most likely to carry hidden characters.

Step 2

Run the check. The text is sent once to our AI server, scanned for hidden Unicode, and nothing further is done with it.

Step 3

Review each flagged character and its location. The result only reports what's there; it changes nothing in the text.

Each of these is an ordinary Unicode codepoint with a legitimate technical purpose, and each can appear as an incidental leftover from formatting or conversion. The scan checks for these specifically:

U+200B zero-width space

Occupies a character slot and renders nothing, the most common invisible character found in copied text.

U+200C / U+200D joiners

Zero-width non-joiner and joiner, meaningful in some scripts and emoji, often a stray leftover elsewhere.

U+2060 word joiner

An invisible joiner preventing a line break at that point, frequently left behind by rich-text conversion.

U+FEFF byte-order mark

Meant to sit at the start of a file, occasionally left stranded mid-document by an export tool.

U+00AD soft hyphen

Invisible until a line wraps there, then a hyphen appears in a word that never had one.

U+00A0 / U+202F non-breaking spaces

Visually identical to a normal space, distinct in code, slugs and search indexing.

Bidi controls (U+202A to U+202E)

Directional embedding and override characters that can quietly reorder how text displays.

This is the point this page states plainly rather than leaving ambiguous. Despite widespread claims online that AI tools embed secret watermarks in their output, that isn't the usual explanation. These characters are overwhelmingly incidental artefacts of ordinary text handling: rich-text-to-plain-text conversion, a chat interface tracking cursor position, a word processor exporting a document, or a mobile keyboard autocorrecting a space.

Copy text out of a Word document, a Google Doc, a PDF, a translated page or a chat window, and some of these characters can travel with it regardless of who wrote the underlying words. A finding here indicates something happened during formatting or conversion, not that the text was produced by an AI model, or by any specific one.

No, and this tool doesn't claim it does. A hidden character is a formatting artefact, not a fingerprint. The same characters appear in human-typed documents exported from Word, in translated text, and in anything routed through a rich-text editor, with no AI involved anywhere in the process.

It's worth distinguishing this from a separate, genuine area of research: statistical, token-level watermarking, in which a model is tuned to slightly bias its word-choice probabilities across a passage in a pattern a statistical test can detect. That technique operates on probability distributions, not inserted characters, and no character-level scan, including this one, can observe it. A claim that an AI watermark can be found by scanning for zero-width characters describes something other than how real watermarking research works.

Several categories of ordinary human workflow produce the same characters, and a serious tool names them rather than letting a finding imply more than it supports.

Word processor exports

Word, Google Docs and comparable tools insert non-breaking spaces and soft hyphens as part of standard formatting.

Translation tools

Machine and professional translation software frequently leaves directional or joining characters behind.

PDF extraction

Pulling text from a PDF commonly introduces stray characters the source document never displayed.

Mobile keyboards

Autocorrect and predictive text can insert a non-breaking space where a regular space was intended.

CMS and rich-text editors

Toggling between rich-text and plain-text views is a routine source of leftover formatting characters.

These characters cause concrete problems once text moves somewhere that parses it strictly. A zero-width space inside a heading splits a keyword, so a page's slug and visible title stop matching. A byte-order mark stranded inside a JSON file breaks the parser. Non-breaking spaces confuse diffing tools, and directional controls can make a URL display differently from how it resolves.

Where a character came from and whether it's currently causing a problem are separate questions. This detector answers the second directly and the first honestly, rather than letting a scan result stand in for a finding it hasn't established.

Editors, developers, publishers and anyone shipping text they didn't type by hand use this to catch formatting problems before they surface downstream. It's server-side by necessity: your text travels to our AI server to be scanned, then the result travels back, which is why the free allowance is metered.

You get 5 free checks in any rolling 24-hour window, tracked without an account. That covers ordinary use, one document, one email, one flagged section at a time, and for a longer batch, spacing checks across the day works better than exhausting the allowance at once.