ChatGPT text cleaner

This ChatGPT text cleaner corrects two independent problems in text copied out of ChatGPT, in a single deterministic pass: the invisible Unicode characters a chat interface's renderer inserts, and the doubled spacing and blank-line runs that come along with them. It is not scoped to one narrow character class the way a zero-width space remover is, and it does not delete every space the way a full whitespace stripper does. It is the general-purpose pass for text about to be pasted somewhere that reads bytes literally rather than just displaying them.

The operation is entirely local. Detection and correction both execute in JavaScript in your browser; nothing is transmitted to a server, so there is no run limit and no length cap to apply, since neither is meaningful for work that costs nothing to run.

A reply reaches your clipboard as the output of a render, not as the plain characters displayed on screen. The interface's formatting layer inserts zero-width and non-printing codepoints to track cursor position and preserve structure across the copy, and it frequently substitutes a non-breaking space for a plain one wherever ordinary HTML would otherwise collapse whitespace it needs to hold. Both effects originate in the same rendering step, which is why they turn up together in the same paste rather than as two unrelated defects.

Treating them as one correction, rather than two separate tools run in sequence, is what keeps the workflow to a single pass.

Three controls are available before you run it: two enabled by default, one that is not because it alters visible punctuation.

Step 1

Paste using ChatGPT's own copy function. A manual selection can omit the characters this tool exists to find.

Step 2

Set the options. Normalize spaces and Collapse blank lines run by default. Enable Straighten quotes and dashes only if you also want curly quotes and en and em dashes converted to a plain hyphen.

Step 3

Run it. The corrected text appears in the output field immediately, with every visible word preserved exactly as typed.

The engine checks a fixed set of 14 codepoints, grouped here by what happens to each one on correction.

Zero-width space, non-joiner, joiner, word joiner (4)

U+200B, U+200C, U+200D, U+2060. Each occupies a position in the text while rendering nothing. A joiner detected inside a genuine emoji sequence is preserved rather than removed.

Spacing look-alikes, normalized rather than deleted (3)

U+00A0, U+202F, U+200A. Visually identical to a plain space, structurally different. Each is replaced with a plain space, not stripped outright.

Removed outright (2)

U+00AD, the soft hyphen, invisible until a line wraps. U+FEFF, the byte-order mark, which can appear mid-document and invalidate strict parsers.

Bidirectional overrides (5)

U+202A through U+202E. Directional controls that can alter display order without changing a single letter of the underlying text.

A zero-width space embedded in a heading defeats an exact-text comparison between the slug and the visible title, so on-page search fails for a term that is plainly present to a human reader. A non-breaking space pasted into YAML or a shell command produces a parse error whose message gives no indication of an invisible cause.

The spacing half of the problem produces its own failure mode: a run of blank lines surviving into a CMS block, doubled spacing surfacing inconsistently once markdown or HTML renders it, a PDF or EPUB export where line breaks land in the wrong place because the source whitespace was never normalized.

This is a deterministic, byte-level and whitespace operation. It does not parse sentences, does not score fluency, and does not flag the openers, hedges or connectors that make a paragraph read as machine-written. That analysis lives in the checker on the homepage, which inspects phrasing directly and explains each flag's reasoning.

Running this tool corrects everything a strict parser, a slug or a database lookup can object to. It has no opinion on whether a sentence sounds like it was written by a person, because that is not what it measures.

No, and treating it as if it did would be a mistake in both directions. Detectors weigh statistical properties of the prose (predictability, sentence-length variance, vocabulary distribution) far more heavily than the presence or absence of a handful of invisible bytes. Removing them corrects formatting; it has no measurable effect on how a detector scores the sentences themselves.

The reverse claim is equally false: finding these characters in a document is not evidence that a person did not write it. Document exporters, CMS editors, PDF copy-paste and translation software all leave comparable residue for reasons that have nothing to do with authorship. Treat a positive scan as a formatting fact, not a verdict.

Engineers pasting AI-drafted config values, sample tokens or snippets, where a non-breaking space produces a failure with no visible trace, run it before the paste rather than after the error. Publishing and editorial teams run it on drafts headed into a CMS, where a hidden character or a run of blank lines causes problems only once the piece is live. Data teams feeding generated text into JSON, CSV or a sitemap use it to rule out a parse failure caused by whitespace rather than content.

It is a single-document, browser-based tool: there is no batch mode and no API, so several documents mean running the tool once per document. That is a deliberate limit rather than a missing feature. The entire design runs on the guarantee that nothing you paste is sent anywhere, and a batch or API surface would need to relax that guarantee to exist.