Gemini character detector
What this Gemini invisible character detector does
This is the check step in a two-step workflow. Paste text you copied out of Gemini, or out of a Google Doc or Gmail draft that Gemini helped write, and the page reports the zero-width and non-printing Unicode inside it. Your text is not modified and nothing is deleted behind your back.
It is a server route, so your text is sent to our AI server to be read. You get 5 free checks in any rolling 24 hours, and each check takes between 1 and 12,000 characters. Plan longer documents as sections rather than trying to push a whole manuscript through one run.
Know what you are chasing
Gemini's text watermark is not one of these characters
Worth settling before you build any process around this. Google's text watermarking works on word choice, biasing which tokens the model picks as it writes. The signal lives in the sequence of words, not in a hidden character between them.
For your workflow this means two separate jobs that are often confused. Cleaning invisible characters fixes search, diffs, slugs and form submissions. It does not touch a token-selection watermark, and no character-based tool on any site does. If someone tells you their character stripper removes Gemini's watermark, they are describing the wrong layer.
The workflow
How to check Gemini text for invisible characters in three steps
Detecting and cleaning are deliberately separate, because you want to see the findings before anything is changed.
- Step 1
- Paste the passage into the box above, as plain text where your editor gives you the option, so you are checking the characters rather than a formatting wrapper.
- Step 2
- Run the check and read the findings. This is where you learn whether the problem is one stray character or a systemic one across every paste from the same source.
- Step 3
- Clean if you need to. This route reports only. The watermark cleaner route on this network is the one that removes, and it runs in your browser rather than on a server.
The checklist
Which invisible characters the scan covers
Our deterministic scanner, the one on this network's watermark routes, covers fourteen characters in four groups. Keep this as your checklist.
- Zero-width and joiners
- U+200B, U+200C, U+200D, U+2060 and U+FEFF. These are the ones that break find-and-replace and URL slugs while occupying a real character slot.
- Space lookalikes
- U+00A0, U+202F and U+200A. They render as a space and are not one, so wrapping and exact search behave in ways nobody can explain by looking.
- Soft hyphen
- U+00AD. Invisible until the line wraps, then a hyphen appears in a word that never had one. This is the one that surfaces in print and PDF export.
- Directional controls
- U+202A, U+202B, U+202C, U+202D and U+202E. Embeddings, overrides and the pop that closes them, which reorder mixed-direction text when left stranded.
- Outside the checklist
- U+200E, U+200F, U+061C, U+2028, U+2029, U+034F, U+FE00 to U+FE0F, U+2061 to U+2064 and U+2066 to U+2069 are named on other tools' pages. Ours does not handle them, so do not treat a clean result as covering them.
Where they come from
Why Gemini output carries invisible characters
Two sources, and knowing which one you are dealing with changes what you do about it. The first is the training data. A model has no keyboard, so nothing stops it emitting a character a person would never type, and the web it learned from is full of no-break spaces, soft hyphens and stray byte-order marks.
The second is the copy path, and this one is fixable at the source. Chat interfaces render to HTML, and copying from HTML picks up whatever the layout used, commonly a no-break space or a hair space around punctuation. Google Docs and Gmail do the same. If every paste from one source is dirty in the same way, the copy path is your culprit and paste-as-plain-text is the cheapest fix.
Why it matters
What invisible characters break in a real workflow
Exact matching goes first. A phrase search fails, a find-and-replace skips a row, a diff reports a change on a line that looks identical, a generated URL slug picks up a character nobody can see or delete. Each of these costs an hour of someone staring at two identical-looking strings.
The sharper risk is that an invisible character is a good hiding place. Text has been concealed inside ordinary-looking sentences this way, including instructions aimed at a model that processes the document later. If your pipeline pastes untrusted text into something that acts on it, checking what is in there belongs in the process, not in the incident review.
Straight answer
Does a finding prove Gemini wrote the text?
No. A no-break space tells you the text came through a rendered page. That page could have been Gemini, a news site, a PDF viewer or a colleague's Word export. Human writing copied from the web carries exactly the same characters, so treat a finding as evidence about the copy path and nothing else.
Removing the characters also does not make a passage read as human to a detector. Detectors work on word choice and sentence rhythm, which is the same layer Google's text watermark occupies. This route reports observable signals and makes no claim about authorship, and no page here promises a result from any third-party checker.
Who uses it
Who builds this check into their workflow
Three teams that run this before publishing rather than after something breaks.
- Editorial teams
- Checking a draft assembled from several sources before it enters a CMS, where a hidden character becomes a broken slug that outlives the article.
- Developers
- Working out why a string comparison fails or why a config value that looks right is rejected, before assuming the parser is at fault.
- Anyone submitting through a form
- Application portals and job boards reject input without saying why. A stray control character is a common and invisible cause.