ChatGPT invisible character detector

Scope

What this ChatGPT invisible character detector does

Paste text from ChatGPT and this page runs an AI analysis on it and describes what it sees, including invisible characters and the other artefacts that come through a copy and paste. Five runs per rolling 24 hours, 1 to 12,000 characters per run, free and no account.

The analysis happens on our AI server, so the text is sent there. That is the trade this route makes, and it buys a description rather than a measurement. Knowing which of those two you need is the whole of the next section.

Step zero

Detector or local cleaner: picking the right step

There are two tools on this site for this problem and they do genuinely different work. Pick before you start rather than after.

This detector

A language model reading your text and describing it. Useful when you want context, or when you are looking at something a fixed list would not capture. Not a counting instrument, and it will not hand you a verified codepoint table.

The local cleaner

The ChatGPT zero-width space remover runs in your browser over a fixed list of 14 invisible and space-like characters. Nothing uploads, there is no usage limit, and every character on the list is found and removed exactly.

The usual answer

If the job is get these characters out of my text, the local cleaner is the tool and this page is not. Use this one when you want the text described rather than changed.

Procedure

How to check ChatGPT text for invisible characters in three steps

Three steps, and step one is where most workflows quietly destroy the evidence.

Step 1

Copy from ChatGPT directly, not from a document you already pasted it into. Some editors normalise on paste, so by the time text reaches you through a second application it may no longer contain what you are looking for.

Step 2

Paste into the box on this page, staying inside 12,000 characters. Leading and trailing whitespace is trimmed before the run, so a space-like character sitting at the very start or end may not reach the analysis.

Step 3

Act on the result with the right tool. A description tells you whether to bother; the local cleaner is what actually removes anything.

Constraints

Working inside 5 runs and 12,000 characters

The limits are real and worth planning around rather than discovering mid-task. The server accepts 1 to 12,000 characters and allows five runs per rolling 24 hours.

Sample, do not sweep

Five runs will not cover a long document. Check a representative section, and if it comes back clean, stop analysing and start cleaning.

Split long pieces at 12,000

Anything longer is rejected outright with a message naming the range. Break at a section boundary rather than mid-sentence so the description stays coherent.

Use the unlimited tool for volume

The local cleaner has no run limit, because it runs in your browser. Any bulk pass belongs there.

The window rolls

The allowance is per rolling 24 hours, not per calendar day, so it refills gradually rather than at midnight.

Failure points

Where invisible characters enter a ChatGPT workflow

Blaming the model is the popular move and it is only part of the story. Characters enter at several points, and most of them are downstream of the chat window.

The generated text itself

The narrow no-break space, U+202F, is the one most often associated with ChatGPT output, typically around dashes and numbers.

The copy button

What ends up on your clipboard is a rendering of formatted output, and formatting artefacts ride along with it.

Word processors and CMSes

These insert no-break spaces and soft hyphens on their own account, entirely independently of AI. A finding here is not evidence of anything about authorship.

PDF and web extraction

Pulling text out of a PDF or scraping a page produces space look-alikes and stray directional controls in quantity.

Transfer between applications

Each hop can normalise, or fail to. This is why checking the copy you are actually going to publish beats checking the one you started from.

Reference

The 14 ChatGPT invisible characters the local cleaner removes

The full list, because a list you can read in full is worth more than a headline number you cannot check. Competing tools advertise 87 and 104; one of them prints fourteen codepoints and then writes 'and 90 more'.

Zero-width group

U+200B space, U+200C non-joiner, U+200D joiner, U+2060 word joiner. Deleted outright, except a joiner between two emoji, which is building a glyph and is left alone.

U+FEFF and U+00AD

A byte-order mark stranded mid-document, and a soft hyphen that stays invisible until a line wrap turns it into a hyphen. Both deleted.

Space look-alikes

U+00A0 no-break space, U+202F narrow no-break space, U+200A hair space. Replaced with an ordinary space rather than deleted, because a space belongs there.

Directional controls

U+202A, U+202B, U+202C, U+202D and U+202E. Invisible controls that reorder displayed text, which is how a link or filename can read as something it is not. Deleted.

Straight answer

Does cleaning invisible characters change an AI detector's result?

No. Originality.ai published a test of this and reported that adding or removing hidden characters did not change the detectability of AI-generated content. That is a measured result, not an opinion.

The reason is structural. Detectors score the words, looking at sentence rhythm, vocabulary distribution and structural regularity. An invisible character contributes to none of those, so removing it moves nothing.

Which means this belongs in a workflow for the reason it actually earns: invisible characters break search, slugs, keys and wrapping. That is a production problem with a fix. A detector score is not.

In practice

When to run a ChatGPT invisible character check

Editorial teams run it at the handoff into a CMS, because a hidden character in a headline or a URL slug is close to undiagnosable once the page is live.

Engineering teams run it on generated strings before they reach code, config or test fixtures, where a zero-width character inside a comparison looks exactly like a logic bug.

Localisation teams run it on anything mixing scripts, since stray directional controls are both invisible and capable of reordering what a reader sees.