The tool
What the Perplexity invisible character detector does
Paste text and press Analyze. This Perplexity invisible character detector sends your text to our server, where it is read and described: what looks like hidden or out-of-place characters, and what in the text is worth your attention. The result is written findings in the second box.
Be clear about what it is, because most tools with this name are something else. This one is a model reading your text remotely. It is not a fixed character-by-character scan running in your browser, and this page will not claim it is. If you want the deterministic scan, the watermark checker in this network runs locally and works from a fixed list.
The premise
Where invisible characters in AI text actually come from
The usual story is that AI models slip hidden markers into their output. Originality.ai tested several models for exactly that and reported the opposite: no model produced an invisible character, while all of them leaned heavily on visible Unicode, em dashes and smart quotes in particular. Its explanation for the visible ones is training data, since models learn from professionally edited text where those characters are standard, and a model is not typing on a keyboard that makes them awkward.
Which means the invisible characters in a pasted draft usually got there on the way. A word processor, a rich-text editor, a CMS field, a browser copy. That is not a reason to stop checking. It is a reason to check the whole path rather than blaming the model and assuming the rest is clean.
How it works
How to check Perplexity text for invisible characters
Three steps, and the text comes back to you unaltered.
- Step 1
- Paste the text, between 1 and 12,000 characters. Paste it from wherever the problem is, because the copy path is often where the characters came from.
- Step 2
- Press Analyze. You can add up to 300 characters of instruction first, for example naming the editor the text passed through.
- Step 3
- Read the findings. Nothing is removed here, so for an actual clean-up use the watermark cleaner, which runs locally against a fixed list.
The list
The 14 characters our local scan covers
This detector is a model read, but the deterministic engine in this codebase has a fixed list of exactly 14 characters, and publishing it is more useful than a vague promise. Three of them are replaced with an ordinary space rather than deleted, because they are space look-alikes and removing them would join two words.
- Zero-width family
- 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.
- Soft hyphen
- U+00AD. Invisible until a line wraps, at which point a hyphen appears in a word that never had one.
- Space look-alikes
- U+00A0 no-break space, U+202F narrow no-break space, U+200A hair space. These three are swapped for a normal space, not deleted.
- Directional controls
- U+202A and U+202B embeddings, U+202C pop directional formatting, U+202D and U+202E overrides. The last one can make a file name read differently from what it is.
The honest part
The invisible characters we do not cover
Competing tools advertise 87 codepoints, or ranges running up to U+E007F. Ours is 14, and the difference is worth naming rather than hiding, because a character we do not handle will still be in your text after a clean run.
Not covered: U+200E and U+200F left-to-right and right-to-left marks, U+2028 and U+2029 line and paragraph separators, U+034F combining grapheme joiner, the variation selectors U+FE00 to U+FE0F, the tag characters U+E0000 to U+E007F, and the typographic spaces U+2000 to U+2009, U+205F and U+3000. If you are chasing a specific character and it is on that list, you need a different tool, and we would rather tell you now.
What not to delete
Why some invisible characters must stay
Stripping every hidden character is not the right answer, and a tool that does it will break things. Other tools in this category warn that zero-width joiners and non-joiners are not always noise, which is correct, and a warning is all most of them offer.
Our engine does something about it. A zero-width joiner sitting between two pictographic characters is treated as part of an emoji sequence and left alone, so a person plus a laptop stays one glyph rather than becoming two. The zero-width non-joiner is a different case: it is genuinely meaningful in Persian and in several Indic scripts, and there is no safe way to tell a meaningful one from a stray one automatically. The engine reports it, and the guidance is to review text in those scripts before cleaning.
Perplexity specifically
The markers in Perplexity output are not noise
One thing to be careful about on this particular route. Perplexity renders numbered inline citations through its answers, similar to an academic paper, with a source list underneath. When you copy the answer out, those bracketed markers travel with the text.
They are visible characters and they are content. A cleanup pass aimed at invisible characters should not touch them, and if you are running any kind of find-and-replace over a Perplexity draft, exclude anything in brackets first. Worth knowing too that Perplexity does not format its sources into APA or MLA for you, so the markers are a pointer to work you still have to do rather than a finished reference list.
Direct answer
Does removing invisible characters beat an AI detector?
No, and the evidence points the other way. If models are not inserting invisible characters in the first place, as Originality.ai's testing indicates, then removing them cannot be taking away a signal that was not there.
We make no claim about Turnitin, GPTZero, Copyleaks or Originality.ai, do not test against them, and are not affiliated with any of them. Nor do we assert anything about a character-based marker in Perplexity output, in either direction. We have seen no evidence of one, and no evidence of one is not the same as proof there is none.