About GPTCleanupPro and its limits

GPTCleanupPro is a large set of narrow text tools, each one addressing a single operation on a single pasted document. The shape is deliberate. A general-purpose text utility with thirty toggles is harder to reason about than thirty pages that each do one thing, both for the person using it and for anyone trying to verify what it claims.

It also makes the claims falsifiable. A page that says it removes fourteen specific codepoints can be checked against the code in about a minute. A page that says it cleans AI text cannot be checked at all, which is why most of the category is written that way.

One list drives both the checker and the cleaner, and it has fourteen entries. Eleven are deleted: U+200B, U+200C, U+200D, U+2060, U+FEFF, U+00AD, and the five directional controls U+202A through U+202E. Three are space look-alikes, U+00A0, U+202F and U+200A, and those are replaced with an ordinary space rather than removed, since the word boundary they occupy is real even when the codepoint is wrong.

The list is bounded, and the boundary is published rather than blurred. Variation selectors, the Mongolian vowel separator, the invisible math operators and the directional isolates U+2066 to U+2069 are not in it and are not touched. Neither are the plain directional marks U+200E and U+200F, which competing pages routinely list alongside the embeddings without distinguishing them.

Naming an exact set is the differentiator, because a page that implies total Unicode coverage fails the first time a reader tests it against a character it does not handle.

The same procedure works on any tool in this category, including this one.

Step 1

Read what it says it handles, and note whether it gives a bounded set or an open-ended description.

Step 2

Open the network panel and run it. A local tool issues no request; a server tool does, and should say so before you paste.

Step 3

Test the boundary. Feed it a character it did not claim, and check whether the page told you the truth about its scope.

Deterministic operations, character removal, whitespace handling, case conversion, encoding, formatting and the watermark scanners, execute in the browser. There is no upload, no allowance and no length cap, because there is no marginal cost per run to meter.

Operations requiring a language model, the rewriters, generators and analyzers, cannot execute locally. Those transmit the document to the server for the run, accept between 1 and 12,000 characters, and allow 5 free runs per rolling 24 hours. Nothing is written to a database or retained after the response returns.

The allowance is therefore diagnostic. A limit exists to meter a cost, so a tool advertising no limit is one that incurs no per-run cost, which means it is running on your machine. That inference is more reliable than any privacy statement, including this one.

Competing pages in this category enumerate nine or ten model names. The enumeration is marketing rather than specification: a codepoint matcher has no model-specific behaviour, so the same fourteen characters are found and handled identically regardless of origin.

The corollary is the part those pages omit. If the operation is origin-blind, a positive result is origin-blind too. Detecting U+200B in a document establishes that the document contains U+200B. It does not establish that a language model produced the text, because word processors, PDF exporters, translation tools and rich-text editors have been emitting the same characters since long before any of these models existed.

Each of these is a position rather than an omission, and each costs traffic on terms this site could otherwise rank for.

No detector guarantee

No page here promises a verdict from Turnitin, GPTZero, Copyleaks or Originality.ai. Those are third-party systems that change without notice, and predicting their output is not something any external tool can do.

No undetectability

Removing invisible characters alters one surface property of a document. It does not alter the statistical properties that classifiers weigh most heavily, and no page here implies otherwise.

No authorship proof

Analysis reports signals. A signal constrains how the text was produced; it does not identify an author, and it is never presented as if it did.

No fabricated figures

No accuracy rates, user counts or testimonials. A competing page asserts that a 500-word reply carries 30 to 50 hidden characters. Nothing measures that, so it does not appear here.

An invisible character occupies a position in a string while contributing nothing to its rendering, which produces a specific class of defect: two values a human reads as identical compare as unequal. Exact-match search returns nothing. A slug fragments. A join key misses. An identifier in source becomes a syntax error with no visible cause.

There is a security dimension most tool pages skip. Directional overrides reorder display without altering underlying content, so a filename or a link can present differently from what it resolves to. Invisible characters are also a documented vector for concealing instructions that a language model reads and a reviewer does not. Stripping them before text enters a system that acts on it is a reasonable control.

Every factual claim here is meant to derive from the implementation. Counts come from the character list, limits come from the request handler, and the local or server designation comes from how the route is wired rather than from how it would be convenient to describe it.

That creates a specific defect class. When behaviour changes and a page still describes the previous behaviour, the page is wrong regardless of how well it reads, and it is treated as a bug rather than a style question.