Paste any text and strip out zero-width Unicode, byte order marks, word joiners, variation selectors, and other invisible codepoints that sneak into copied content. Everything runs in your browser, no signup, no upload, no logs.
What this tool actually does
A zero-width character is a Unicode codepoint that takes up no pixels on screen but still exists in your string. It shows up in word-count totals. It counts against character limits on Twitter, LinkedIn, and meta tags. It can trigger validation errors in CMS systems that expect clean ASCII. It can leak through copy-paste into places it does not belong, a journal submission, a legal filing, a commit message, where it causes confusing downstream bugs.The tool targets the codepoints most commonly encountered in pasted content: zero-width space (U+200B), zero-width joiner (U+200D) and non-joiner (U+200C), the byte order mark (U+FEFF), the word joiner (U+2060), bidirectional marks (U+200E, U+200F), all 16 variation selectors (U+FE00 to U+FE0F), and a handful of legacy separators like the Mongolian vowel separator (U+180E) and soft hyphen (U+00AD). For each removal, the tool shows a per-codepoint count so you can see exactly what was in the input before it went away.
Where invisible characters come from
Most invisible characters in modern text come from three sources. First, rich-text editors and PDF exporters often emit a byte order mark at the start of a file, or insert zero-width joiners when they copy emoji sequences. Paste from a PDF, and you frequently get extra U+FEFF bookends and a scatter of U+200B between words that were typeset with manual kerning.Second, Arabic, Persian, Devanagari, and several other scripts use zero-width joiners and non-joiners as part of correct orthography, they tell the font how to render ligatures. When multilingual text crosses into an English pipeline, those characters travel with it. For languages that need them, keep them. For English prose, strip them.Third, a small number of LLM prototypes experimented with watermarking output via zero-width Unicode. The practice never became industry standard, but enough proof-of-concept code leaked into the wild that AI detectors now sometimes treat dense zero-width content as a suspicious signal. If you are running text through a humanizer or detector and seeing unexpected results, strip invisible characters first and try again.
When you should not use this
Two cases need manual review. First, if your text contains complex emoji sequences, family groupings, skin-tone modifiers, flag codepoints, stripping the zero-width joiner (U+200D) will decompose those emoji into their separate base characters. The text still reads, but the emoji split. If emoji accuracy matters, inspect the output before pasting it anywhere.Second, if your text is in a script that requires zero-width joiners for correct rendering (Arabic, Persian, Devanagari, Gujarati, Bengali, Tamil, and several others), stripping those characters will produce technically legible but orthographically wrong output. The tool is tuned for English and Latin-script content. For multi-script documents, strip invisible characters only from the sections that are plain English.
How this fits a larger writing workflow
Cleaning invisible characters is usually step one of a three-step flow when you are working with AI-assisted writing. Strip invisible characters first. Then run the text through an AI detector to understand how strongly it reads as machine-generated. If the detection score is high, run it through a humanizer and re-check. The reason to strip first is simple: invisible characters add statistical noise that confuses both detectors and humanizers. A clean input produces a clean signal.If you want to run the cleaned text through Leap's free AI detector, see the detector page. If it scores high and you want to rewrite, Leap's humanizer takes the cleaned text and cleans up stock phrases, em dashes, and uniform sentence length. Both are free and run in your browser without signup.