How to remove zero-width characters safely
Invisible characters are easy to remove and hard to reconstruct after the context is lost. Preserve the source in your own secure workspace, then inspect the exact final string. Copying through chat, a rich-text editor, or a document converter may already normalize the content, so use the version that will actually enter your publishing or data pipeline.
A useful scan reports code point names and positions rather than simply saying “hidden characters found.” NoLLMWM shows UTF-16 positions, which match JavaScript string indexing. A Python or command-line tool may report Unicode scalar or byte positions, so compare the character sequence as well as the number. Reproducibility matters more than identical index conventions.
Remove clearly accidental spaces first
In plain English copy, an unexpected U+200B ZERO WIDTH SPACE inside a word or an internal U+FEFF byte-order mark is often residue from copy and paste. Unicode tag characters outside a recognized emoji sequence can also be suspicious. The local cleaner preselects these narrow cases. Review where each appears, remove the selected instances, and scan again.
Do not assume origin. An accidental control does not prove AI generation, tracking, or malicious intent. It may come from layout software or an old export. Describe the operation factually: which code point was removed, from which authorized copy, and what checks were performed afterward.
Preserve joiners and variation selectors
U+200D ZERO WIDTH JOINER and U+200C ZERO WIDTH NON-JOINER are not generic clutter. They affect emoji composition and the shaping of multiple writing systems. U+FE0E and U+FE0F select text or emoji presentation for certain symbols. Removing them can split a family emoji, change the appearance of a profession symbol, or alter a word even though a simple Latin test looks fine.
NoLLMWM does not list these as default removal candidates and counts recognized formatting context separately. If a security review specifically requires changing one, involve a language or encoding specialist and test on every target platform. A universal regular expression that deletes the U+200B–U+200F range is unsafe because it spans characters with different jobs.
Treat bidi and typography controls as manual decisions
Left-to-right and right-to-left marks, embeddings, isolates, and pop controls guide display order. They can be legitimate in Arabic, Hebrew, Persian, and mixed-direction interfaces. Direction overrides can also conceal the apparent order of filenames or code. The right response depends on the intended visual sequence and security context, which a generic cleaner cannot infer.
Soft hyphens and word joiners affect line wrapping. A character may seem unnecessary on a wide screen and become important in a narrow column. NoLLMWM reports these characters with warnings and does not preselect them. If you choose removal, review line breaks and copy behavior at realistic widths and in the final destination application.
Validate the cleaned result
Run a second scan on the cleaned string. Compare visible rendering, code, links, search matches, emoji, multilingual names, and right-to-left fragments. Read the passage for meaning because invisible controls can affect how identifiers or sentences appear. For production content, test a representative export and round trip through the content-management system.
Unicode normalization is not a substitute for this review. NFC and NFKC apply defined equivalence transformations; they do not simply erase every invisible control, and compatibility normalization may change identifier semantics. Apply normalization only when the receiving system has a documented normalization contract. Make each cleanup explicit and reversible until validation is complete.
- Scan the exact source and preserve a private original.
- Remove only understood instances, not entire character ranges.
- Rescan and test rendering in the destination.
- Record a scoped result instead of claiming universal watermark removal.
Know when another tool is required
A pasted string does not expose PDF properties, DOCX revision history, HTML resources, EXIF, XMP, C2PA assertions, or pixel-level image signals. If the concern comes from a file rather than its extracted text, use a parser designed for that format and consider the provenance consequences before removing metadata. Keep NoLLMWM’s text result separate from the file result.
Likewise, statistical token watermarks are carried by wording rather than hidden characters. Selective Unicode cleanup cannot address them. An authorized rewrite changes the token sequence, but an independent product still cannot guarantee a private vendor detector outcome. Choose the next step based on the signal you actually observed.