Clean AI Text — Remove Hidden Characters and Messy Formatting

What clean means on this page

Two separate jobs, done in one pass. The first is invisible characters — the zero-width and directional code points that leave no visible trace. The second is visible-but-wrong formatting: three blank lines where you wanted one, a paragraph indented with a mixture of tabs and spaces, line endings from two different operating systems in the same document.

Both come from the same root cause. Copying rendered text through several applications means carrying several applications' idea of what whitespace is. Cleaning is the process of settling on one.

Formatting problems that survive copy-paste

Non-breaking spaces are the worst offenders, because they look exactly like spaces and behave nothing like them. A line that will not wrap, a table column that refuses to align, a search that misses a phrase you can see — all three are commonly a single non-breaking space.

Then there are the line endings. Windows uses two characters per break, most other systems use one. Paste one into the other and the leftover renders as an extra blank line, which is why text copied from a document often arrives double-spaced.

A repeatable cleanup routine

Paste into the left box and press Clean. Read the report before you copy — it tells you which category of problem you had. Zero-width characters in bulk mean the text came straight from a rendered answer. A handful of non-breaking spaces mean it went through a word processor.

Then copy the result and paste it into its destination. If the destination is a web form that strips formatting anyway, you lose nothing. If it is an editor, you have removed the layer that editors handle worst.

Before you hit publish

Run the headline and any subheadings through separately. Invisible characters in a title cause layout problems that are hard to attribute, and a title is short enough to check in seconds.

For long pieces, clean the whole draft in one pass and use the report as a signal about your own workflow. If every draft reports the same character types in the same proportions, the fix belongs upstream — in how you copy, or in what you copy through.

What AI text actually contains — and why your eyes miss it

When a language model produces text, the output is a sequence of tokens rendered into Unicode. That rendering process introduces several categories of character that look correct on screen but behave badly everywhere else. Knowing which characters appear and why makes cleaning less of a guessing game.

Smart quotes — the curly variants ‘’ and “” — are the most visible. Many models produce them because their training data contained them. The problem is not appearance but matching. A search for the word don't using a straight apostrophe will not find a paragraph containing don’t with a right single quotation mark. Regex that looks for quoted strings with " will miss passages surrounded by “ and ”. If you pipe AI output into any system that does pattern matching — a linter, a template engine, a find-and-replace script — straight quotes are what you need.

Non-breaking spaces (U+00A0) are invisible by design. They were invented to prevent a line from breaking between two words — for example, between a number and its unit. Models pick them up from training corpora that used them correctly, and they arrive in your text without any signal that they are present. A CMS search index treats U+00A0 as a different character from U+0020, so the phrase appears twice and matches neither query. A WordPress editor will sometimes convert a U+00A0 into its HTML entity   on save, producing output like cost per click mid-sentence in the raw HTML.

Zero-width characters — primarily U+200B (zero-width space) and U+200C (zero-width non-joiner) — have no width and cast no shadow. They exist in rendered text for ligature control and bidirectional text handling. In plain prose they do nothing useful and break many downstream systems: CSV parsers that count field delimiters, tokenizers that split on Unicode word boundaries, and content-moderation filters that score n-grams. The only reliable way to find them is to examine the raw byte sequence, which is what this tool does.

Markdown remnants appear when a model is asked to produce plain text but defaults to Markdown syntax. The most common are double asterisks around bold phrases (**like this**), underscore italics, and pipe-delimited table rows. These pass through to the reader as literal punctuation if the destination does not render Markdown. A headline like **Key Findings** published to a plain-text email list reaches readers as literal asterisks. Tables with pipe characters and dashes end up as visual noise in any system that expects prose.

Knowing the category tells you what to clean. Smart quotes and Markdown are visible and easy to audit. Non-breaking spaces and zero-width characters require a tool that operates on code points, not glyphs — which is exactly what this page does.

Where to put the cleaning step in your workflow

The right moment to clean is the moment before text crosses a boundary — before it moves from one system to another. Every boundary is a potential mismatch between what the sending system considers normal whitespace and what the receiving system expects.

Before pasting into a CMS: Paste raw AI output into the tool, clean it, then paste the result into your CMS. Do not paste raw output directly and then clean inside the CMS editor, because some editors silently re-encode characters on every keystroke and you may end up cleaning a different character set than the one the model produced.

Before importing into a spreadsheet: Excel and Google Sheets both handle Unicode reasonably well, but non-breaking spaces inside cell values will cause TRIM() to leave trailing gaps that look like empty space. A cell containing a product name with a trailing U+00A0 will not match a VLOOKUP for that name with a trailing space, even though both look identical. Clean before import to avoid ghost mismatches that take hours to diagnose.

Before feeding into a second API call: If you are chaining calls — using the output of one model as the input of another, or passing AI text to an embedding API for semantic search — residual invisible characters widen the token count and add noise to the embedding. More practically, prompts that include smart quotes may behave differently from prompts with straight quotes because the model tokenizes them differently. Cleaning the intermediate text keeps the chain predictable.

What not to clean: If the destination renders Markdown, keep Markdown. If the destination expects HTML entities, do not strip them. The minimum necessary cleaning principle says: identify what the destination cannot handle and remove only that. This tool reports what it found so you can decide which categories to act on. A document going into a Markdown renderer needs zero-width characters removed but not asterisks. A document going into plain email needs both removed.

For high-volume production use, the same logic applies at scale. When you are processing hundreds of pieces, run the cleaning step as a transformation stage in your pipeline — after generation and before storage. That way your database never accumulates hidden characters and you do not have to re-clean at retrieval time.

What cleaning fixes and what it does not — the human editor's share

A character-level cleaner operates on code points. It finds and replaces or removes specific Unicode values. That scope is both its strength and its limit. Being precise about what the tool does and does not fix prevents the mistake of cleaning text and then assuming it is ready to publish.

Cleaning reliably fixes: straight-quote normalisation, non-breaking space replacement, zero-width character removal, duplicate blank line reduction, mixed line-ending normalisation, and Markdown syntax stripping. These are deterministic operations with no ambiguity. Every U+200B in the input is gone from the output. Every sequence of three or more blank lines becomes one. The report confirms each change with a count.

Cleaning does not fix factual errors. A sentence that states the wrong year, attributes a quote to the wrong person, or inverts a cause-and-effect relationship passes through unchanged. The tool has no model of the world and no way to evaluate claims. Fact-checking remains entirely the editor's responsibility.

Cleaning does not fix repeated ideas. Many AI outputs contain the same point restated in different words across three or four paragraphs. These are distinct sentences with distinct characters; a character-level tool sees no repetition. Cutting redundant passages is an editing task.

Cleaning does not fix tone or register. Phrasing that is too formal, too casual, too hedged, or too assertive for the audience is a matter of word choice. Normalising whitespace does not change any word.

For batch processing — say, 500 pieces generated overnight — the practical approach is one cleaning pass over all 500 (scriptable with the same regular expressions this tool applies: strip zero-width characters, replace U+00A0, normalise line endings, remove Markdown syntax markers), followed by manual spot-checks on a random sample of 10 to 15 pieces to verify that the cleaning step did not introduce new problems. Common introduction errors are over-aggressive regex that strips valid hyphens or removes apostrophes inside contractions. The spot-check sample should include pieces from different topic areas and different prompt templates, since different prompts tend to produce different character distributions. If the sample is clean and the character report shows consistent categories across the batch, the rest can be accepted without individual review.