A zero-width space remover with limits

U+200B is the search term, but it is one member of a family and rarely the only one present. This route matches fourteen codepoints in the input, deletes eleven of them, substitutes an ordinary space for the three that are space look-alikes, and returns every other byte unchanged. It then reports how many characters were removed or changed.

Processing is local. The transform is a JavaScript pass over the string in the page, so no request is issued, nothing is retained, and there is no account, rate limit or length ceiling to apply. That is a property of the architecture, not a policy, and a network panel confirms it in seconds.

A page advertising a number should print the list. Grouped by the job each character does.

Zero-width family

U+200B space, U+200C non-joiner, U+200D joiner, U+2060 word joiner. Zero advance width by design, used to control joining and line breaking. Deleted.

U+FEFF byte-order mark

An encoding signal legitimate only at the head of a stream. Mid-document it is a parser hazard. Deleted.

U+00AD soft hyphen

A conditional hyphenation point, invisible until the line wraps on it. Deleted.

Space look-alikes

U+00A0 no-break space, U+202F narrow no-break space, U+200A hair space. Substituted with U+0020 rather than deleted, because the gap is semantically real.

Directional controls

U+202A and U+202B embeddings, U+202C pop, U+202D and U+202E overrides. Bidirectional layout machinery. Deleted.

Order matters, because the diagnostic value disappears once the text has been re-rendered.

Step 1

Paste the original clipboard content. Any intermediate step that re-renders the text, including a plain-text editor or a form field with input sanitising, can strip the characters before the run sees them.

Step 2

Run the removal. The output differs from the input only at the matched positions, and the count of changed characters is reported.

Step 3

Copy the result and, if the source matters, keep the original. A cleaned copy cannot be re-examined later.

Three alternatives circulate in guides for this term, and each has a specific failure mode worth knowing.

The plain-text paste-through, into Notepad or TextEdit, works by discarding rich-text formatting, so the invisible characters go along with the styling. It is fast and it is lossy: your bold, your links and your list structure go too. It also does nothing for text that was already plain when the characters entered it.

Editor find-and-replace with Unicode escapes is precise but sequential. You run one pass per codepoint, which means you need the list before you start, and a codepoint missing from your list is a codepoint left in the file. This is the method most likely to produce a false sense of completion.

A scripted pass with a character class is the most reliable of the three and the only one that scales, at the cost of setting up an environment for one paragraph. This page is that pass, with the class already written and its membership published.

Four boundaries. First, invisible characters outside the set: U+2009 thin space, which other pages in this result set name, along with variation selectors U+FE00 to U+FE0F, the Mongolian vowel separator U+180E, the invisible math operators U+2061 to U+2064 and the directional isolates U+2066 to U+2069. If a problem survives a clean run, those are the reasonable next place to look.

Second, every visible character. Em dashes, en dashes, smart quotes, ellipses, asterisks and Markdown syntax all pass through unchanged. Competing tools bundle those transforms into the same button, which makes their output harder to reason about, not easier.

Third, whitespace structure. This route does not collapse repeated spaces or blank lines and does not trim the ends of lines. The general cleaner does that, deliberately on a different page.

Fourth, inference. A finding shows the text passed through a pipeline that emits these codepoints. It does not identify the author, and a clean result does not establish human authorship, because any normalising step in between strips them incidentally. No result here predicts what a detector will say.

The damage has one shape: a string that looks equal to another is not equal to it. That breaks exact-match search, join keys in a data load, deduplication, cache keys and URL slugs. The symptom is a null result rather than an error, which is why these cost so much time to find.

In source code, a zero-width character inside an identifier produces a parse failure the editor gives no sign of. In publishing, a byte-order mark in the body renders as a stray glyph or fails a validator.

The security case is narrow but real. U+202D and U+202E override the display direction of what follows, so a filename or link can render differently from what it resolves to, and invisible characters are a documented carrier for instructions aimed at a model rather than a reader.

Take the reported count, then check it without trusting the page. Compare the character length of the input and the output in any counter: the difference should equal the number of deleted characters, with substituted spaces contributing nothing to that difference. Word count should be stable unless a zero-width space was standing in for a real space.

A second run on the output is the stronger test. It should report no change, because the fourteen are gone. If it reports something, the input was edited in between.