Zero width space remover for Perplexity

The transformation is narrow and fully specified. Fourteen codepoints are in scope. Eleven are deleted. Three, the space look-alikes, are mapped onto U+0020 rather than removed, because deletion would concatenate the adjacent tokens. Every other byte in the input survives to the output unchanged, including whitespace runs, blank lines, Markdown syntax and punctuation.

That narrowness is deliberate and it is the argument for using this rather than a general AI text cleaner. A transformation you can predict character for character is one you can run on a document you have already reviewed. A cleaner that also rewrites punctuation and flattens Markdown forces a second review of the output.

Perplexity ships a workspace feature named Spaces, which holds threads, files and standing instructions. Removing one is an account operation performed inside the product. A result set for this phrase mixes those tutorials in with Unicode tooling, so the distinction is worth making before anything else on the page.

This tool addresses the character class: zero-width, hair and no-break spaces present in the byte stream of a copied answer. The two share a noun and nothing else.

Published in full, because a removal set that cannot be enumerated cannot be verified.

Deleted: U+200B, U+200C, U+200D, U+2060

Zero-width space, non-joiner, joiner, word joiner. Zero advance width. A joiner occurring inside an emoji sequence is detected by context and preserved.

Deleted: U+FEFF

Byte-order mark. Meaningful only as the first unit of a stream; a defect at any later offset.

Deleted: U+00AD

Soft hyphen. A conditional break opportunity that renders only when the break is taken.

Deleted: U+202A, U+202B, U+202C, U+202D, U+202E

Directional embeddings, the terminating pop, and the left-to-right and right-to-left overrides.

Mapped to U+0020: U+00A0, U+202F, U+200A

No-break, narrow no-break and hair space. Visually equivalent to a space at most sizes, distinct under every byte comparison.

The computation is local and linear in the length of the input. Nothing is transmitted, queued or retained.

1. Capture faithfully

Copy from the rendered answer, not through a plain-text buffer. An intermediate buffer strips the characters and leaves you measuring nothing.

2. Transform

The result reports the delta in characters removed or changed, which distinguishes a clean input from a tool that did not run.

3. Verify by comparison

The visible text is invariant under this transformation. Any perceived change in wording is a copy error, not the cleaner.

This route calls the cleaner with space normalisation and blank-line collapsing both disabled, and punctuation normalisation is off by default and not enabled here. The consequences are worth listing because comparable tools do the opposite silently.

Whitespace runs are not collapsed. Blank lines are not merged. Markdown is not stripped: headings, emphasis, lists, links, blockquotes and fenced code all survive intact. Curly quotes are not straightened. Em and en dashes are not converted to hyphens. A horizontal ellipsis stays a single character. Trailing whitespace is not trimmed. If a competing cleaner has already done those things to your text, this one will not undo them either.

Perplexity composes answers from documents it fetches. Those documents were typeset by publishing systems that insert invisible characters correctly and on purpose: narrow no-break spaces before units, soft hyphens at wrap candidates, byte-order marks emitted by exporters. The characters are valid in their original document and become noise the moment the surrounding text is quoted elsewhere.

A model generating without retrieval has a single residue path, the rendering of its own output. A retrieval engine has two, and the second is governed by third-party typesetting it does not control. That asymmetry is the reason a Perplexity-specific route is not merely a keyword variant of a generic cleaner.

Model routing supplies a third source of variance. Perplexity directs answers to a model the user selects, so residue profiles differ across sessions on one account. Inconsistency is the expected behaviour, not a defect.

The failure never surfaces where the character sits, which is what makes it expensive. A zero-width space inside an H2 splits the keyword token, so a slug generated from that heading diverges from the rendered title and the two drift apart permanently. A no-break space inside a spreadsheet formula or a shell argument produces a type or parse error that names the wrong culprit.

Beyond that: find-and-replace misses matches that are visibly identical, CSV and JSON imports reject a field that looks correct, screen readers insert a pause mid-token, and a version control diff records a modified line with no visible modification. Each of these is cheap to fix and expensive to diagnose.

No, and the mechanism explains why. Detectors model lexical choice, syntactic variety and the statistical predictability of token sequences. Invisible characters contribute to none of those, because they are stripped or ignored before the text reaches the model doing the scoring. The input is functionally identical before and after this transformation.

The correct justification for running it is engineering hygiene. Text entering a content system, a repository or a data pipeline should not carry characters that break tokenisation in those systems. That is a real defect with a real fix. A page that offers a stronger promise than that is describing something the transformation cannot deliver.