Remove ChatGPT Formatting and See What Was Hiding in Your Text

Two different complaints share the phrase. One is about things you can see: heading hashes that arrived as literal ## characters, bold markers sitting in the middle of a sentence as **, bullet glyphs that will not line up with the rest of a document. That is a formatting problem, and it is annoying but obvious.

The other is about things you cannot see. A no-break space where a normal space should be. A zero width character wedged between two letters. A Cyrillic а standing in for a Latin a. Nothing looks wrong. Your search still fails, your import still rejects the row, and you spend twenty minutes staring at two strings that are identical on screen.

Most tools that offer to remove ChatGPT formatting handle both, then hand you a clean block and leave. The part that is missing is the diagnosis. If a tool quietly deleted eleven characters from your text, you would want to know which eleven, and whether any of them were doing a job. That is what the panel above is for, and it is why the detection runs before the cleaning rather than as a footnote to it.

The consistent theme is silent failure. A visible bug announces itself. These do not. An HTML class attribute splits into separate class names on ASCII whitespace, and U+00A0 is not ASCII whitespace, so class="btn primary" with a no-break space in the middle becomes one class name that neither .btn nor .primary will match. No error is raised anywhere. A byte order mark at the head of a file is similar: JSON.parse throws on it at position zero, and the message quotes the opening brace rather than the character sitting in front of it.

Code review is the worst of it. GitLab has an open issue titled Highlight zero-width space changes, which opens with the observation that in a diff, one cannot see that a line includes a zero-width space change, and that as these spaces can break things they should be highlighted. A reviewer sees a line marked as changed and no change in it.

Outside code, it shows up as search that finds nothing. A soft hyphen inside a product name splits it invisibly, so a support agent searching for the name gets no results while looking straight at it. Spreadsheet imports do something similar with figure spaces from PDF tables, where a column split on whitespace produces one long cell.

None of this is dramatic. It is a category of bug that costs an hour at a time and never leaves a trace worth writing up, which is why so few people go looking until it has happened to them twice. It is also the honest reason to remove ChatGPT formatting from anything headed for a database, a config file or a pull request.

A naive cleaner is a search and replace over a list of codepoints, and it will damage real text within about a minute of use. Three cases matter enough that this tool refuses the obvious behaviour.

The first is emoji. A family glyph is several emoji held together by U+200D, the zero width joiner. Strip every joiner and one picture becomes four. So the joiner is only removed when it is not sitting between two emoji.

The second is Arabic and Indic script, where U+200C controls whether adjacent letters connect. It is not an artifact there, it is spelling. The same check applies: a joiner next to those scripts stays where it is.

The third is the lookalike letters, and this one is the easiest to get wrong. A Cyrillic о inside the English word confidential is almost certainly a problem. The identical character inside a Russian word is the correct letter, and converting it produces nonsense. So the tool reads the whole word first: it substitutes only when the word already contains ASCII Latin letters and contains no Cyrillic or Greek letter that lacks a Latin lookalike. Genuine Russian and Greek pass through untouched, and you can confirm that with the sample pastes above.

The lookalike mappings follow the confusable character data described in UTS #39, Unicode Security Mechanisms. The word level guard is ours, not part of that specification.

It is not a way to change what an AI detector says about your writing. Those tools score the text itself: vocabulary, sentence length variation, how predictable the next word is. Punctuation is a small input at best. Replacing every em dash leaves the sentences saying the same thing in the same order, which is the part being measured, so treat any score movement as noise rather than progress.

It also will not fix writing that sounds like a template. If the reason you are here is that a draft reads as though nobody wrote it, the fix is in the sentences rather than the characters. Wanting to remove ChatGPT formatting and wanting to sound less like a chatbot are two different jobs, and this tool only does the first one.

And it cannot tell you where a character came from. A no-break space is a no-break space whether a word processor, a chat model or a web page put it there. Anyone claiming to identify the source of a hidden character from the character alone is guessing.

Detection and cleaning share one code path, which is the whole design. Ask it to remove ChatGPT formatting and the scanner first produces a list of edits against your original text, each with an offset, a length and a replacement, and the cleaned output is that list applied in order. The count in the panel is therefore the number of edits your text received, not a separate tally that could drift away from reality.

Overlaps are resolved rather than ignored. Two rules can want the same offsets, so the passes run in a fixed order and the first rule to claim a span keeps it. Everything downstream depends on that, because the moment two edits touch the same range, the count in the panel stops describing the output.

The em dash is the only character whose replacement depends on context. Replacing one — two with a bare hyphen would leave a space either side of it, so the rule looks at what is already there and supplies only the spacing that is missing. At the start of a line it becomes a list marker instead, because that is what it was being used as.

The scan runs on every keystroke against a deferred copy of your text, so typing stays responsive on long pastes, and the inline preview stops rendering above twenty thousand characters while the counts and the output continue to cover everything.

A test suite covers the behaviour described here. It checks that cleaning twice gives the same result as cleaning once, that fixtures containing CJK, emoji, accented Latin, Arabic and Russian come through with every visible character intact, that switching a pass off leaves its characters alone, and that the findings the panel reports are exactly the edits the output received. That is fixture coverage rather than a proof over all possible text, and two of those tests exist because an adversarial review of the first version found the cleaner deleting an em dash at the end of a line.