Remove Invisible Characters

What Are Invisible Characters?

Unicode contains a family of characters that have no drawn shape, show nothing on screen, and yet really occupy a position in the text. The best known is U+200B, the zero width space. It has zero width, you cannot select it visually, but it counts toward the character total, breaks a search, blocks a login when it lands in a password field, and produces a baffling compiler error when it lands in a line of code.

The rest of the family behaves similarly. U+FEFF is normal as a byte order mark at the start of a file but has no business in the middle of a paragraph. U+00AD, the soft hyphen, only appears at a line break. U+2060, the word joiner, prevents one. The U+E0000 tag block is the most telling of all: those characters have no function in ordinary writing at all, and exist in practice only to hide a message inside plain text.

How do they get into the text?

When you copy an answer out of a chat with a language model and paste it into a document, you do not only copy the letters you can see. The interface renders the text as HTML, and wrapping hints, component separators and occasionally deliberate markers all travel to the clipboard with it. The same thing happens when you copy from a web page, a PDF or a Word document. So finding an invisible character tells you the text passed through an interface. It does not tell you who wrote it.

Which Markers Mean Something and Which Are Innocent

The most common mistake is treating every finding as equally incriminating. The table below shows how much information each of the main markers actually carries.

In short: the innocent characters make up the noise, and the meaningful ones are rare. A hundred no-break spaces tell you nothing. One tag character tells you a great deal.

How Hidden Messages Are Embedded and Decoded

Saying that invisible characters exist is cheap. The useful part is saying what they say. This tool tries four schemes and reports which one matched.

• Scheme A, Unicode tag characters. The U+E0000-U+E007F block mirrors ASCII one to one: subtract 0xE0000 and U+E0020 through U+E007E land exactly on 0x20-0x7E. U+E007F is usually a terminator. This block is the standard way to smuggle invisible instructions into plain text, and when it is aimed at a language model the technique is called ASCII smuggling. Because it has no legitimate use in running text, even a short run is worth reporting.
• Scheme B, variation selectors. U+FE00-U+FE0F holds sixteen values and U+E0100-U+E01EF holds two hundred and forty. Together that is exactly 256, so each selector can encode one byte by its index in the concatenated range.
• Scheme C, zero width binary. Two distinct zero width codepoints stand for 0 and 1, at 8 or 16 bits per character. The most common pairs are U+200B with U+200C, or U+200C with U+200D, sometimes with U+200D or U+FEFF as a separator. Encoders do not agree with each other, so the tool reads the alphabet out of the run itself instead of assuming one.
• Scheme D, zero width base three or four. The same idea in a different radix: three or four distinct zero width characters used as digits.

This feature is only worth having if it does not cry wolf, so a payload has to clear several gates before anything is reported. The characters must form a contiguous run, because a scattered single U+200B at a word boundary is a content management system's line break hint rather than data. The alphabet must be narrow: a real binary payload uses exactly two distinct codepoints, and six different zero width characters mixed together is paste debris. The length must divide by 8 or 16. And the decoded result must be plausible printable text; high entropy garbage is rejected rather than displayed. If none of the schemes fits, the answer is explicit: these characters do not decode to readable text under any scheme this tool knows. The tool never guesses, and it never partially guesses.

What a Character Proves and What It Does Not

A measurement describes the text. An inference describes the author. This tool only does the first, and that is a choice rather than a technical limitation. A U+200B is either there or it is not; anyone can reproduce that on their own machine and prove us wrong if we are. A percentage can be neither reproduced nor refuted, only believed or disbelieved. That is why there is no percentage here.

Start with this site itself

This blog's configuration file has Goldmark's typographer enabled. The practical consequence: of the 72 Turkish post sources, 71 contain straight quotes, yet every published page shows curly ones. No human performed that conversion, a compiler did. Press the "Sample from a publishing pipeline" button above and every finding you see was produced by software. Treating typographic tells as a fingerprint reads the publishing toolchain, not the writer.

Invisible characters are a provenance artefact, not a watermark

Two claims sound alike and are constantly confused. The first is that these characters show up in language model output: that is true, and this tool measures it. The second is that language models use these characters to watermark text: there is no support for that. Originality.ai explicitly rejected the watermark reading on a published page, and their reasoning holds up. A watermark has to be hard to remove in order to be worth anything, and these characters vanish with one click, for instance with this page. The April 2025 U+202F episode points the same way: the behaviour disappeared within about a day and was explained as a by-product of large scale reinforcement learning rather than a watermark. Whatever else a watermark is, it does not vanish in a day.

Removing them does not change what a detector says

There is a direct measurement of this. Originality.ai tested it with their own detector: adding invisible characters to a text or stripping them out did not change the result. Honesty requires noting that this is a vendor testing its own product and that it has not been independently replicated. The result is not surprising though, because statistical detectors look at the distribution of word choices rather than at whitespace. The practical meaning here is plain: this tool is no use for beating a detector, and we did not build it for that.

What is left from the era of statistical detection

The history of this field is worth knowing, independently of anyone's current accuracy claims. Vanderbilt University disabled Turnitin's AI detector in August 2023 and published its reasoning. The arithmetic was this: at the vendor's then-stated one percent false positive rate, against roughly 75,000 submissions a year, about 750 papers a year could be wrongly flagged. Turnitin later revised its own false positive rate upward to about four percent at the sentence level. A widely cited 2023 study measured that detectors of that era flagged non-native English writers disproportionately, attributing it to those detectors penalising constrained linguistic expression. Other universities followed Vanderbilt in switching the detector off.

We draw no conclusion about today from that, and we suggest you do not either. The study measured detectors of the 2023 era. Vendors have since published markedly better figures, including claims of reduced false positives for non-native writers. We are not in a position to say whether those claims are true or false: as far as we could establish, they have not been independently replicated. We are stating our own uncertainty plainly, because that is exactly what makes this section worth reading.

One more note. GPTZero, the best known detector built on perplexity and burstiness, said publicly in autumn 2023 that it had moved off that approach in favour of a trained model. In other words, the popular signals of that era, including the sentence length measure on this very page, were not considered good enough by the people selling them.

So what are these characters good for?

Not for identifying an author, but for knowing what your text actually is. A curly quote that lands in a code block stops the build. A zero width space makes a search fail to match, makes two records compare unequal, and makes a password field silently reject you. In Excel it turns a number cell into text. In a database it corrupts a primary key. These are real, reproducible, fixable problems, and this tool was built for them.

What to Do If a Detector Accused You Unfairly

First, plainly: this tool produces no evidence either for you or against you. Finding nothing in your text does not clear you, and finding something does not incriminate you. What actually speaks to authorship is not the text but the process.

• Show the process. Google Docs and Word version history reconstruct how the text grew minute by minute. A document pasted in one go and a document written over two weeks look nothing alike in that view.
• Keep the intermediate artefacts. Notes, drafts, outlines, source lists, handwritten plans and browser history together make a strong record. They are hard to manufacture afterwards and easy to accumulate as you go.
• Ask for the rate. Ask whoever made the accusation, in writing, for the detector's false positive rate and the independent study that established it. Very often no such number exists.
• Produce a control. Feed the same detector something you wrote years before these models existed. The result frequently refutes itself.
• Get it in writing. Ask the institution to confirm in writing that a detector output alone cannot be grounds for a penalty. Vanderbilt and many other universities have already changed policy in exactly that direction, and that precedent can be cited.

How to Clean a Document Without Breaking It

This section is for people who are not chasing AI at all, only trying to fix a document that broke. Invisible characters cause trouble in Word, Excel, Google Docs, Notepad++ and Figma content on a regular basis, and the source is usually mundane: a paste from a web page with formatting, a PDF copy, a bad export or a translation tool.

1. Strip only the invisible characters first. Zero width characters, the tag block and the directional controls are almost always unwanted, and removing them does not change how the text looks at all, which makes this the lowest risk step.
2. Be careful with spaces. A no-break space is sometimes deliberate: "10 000 km", "Prof. Jane Smith", or a table column that must not wrap. Leave this option off for text going to print and turn it on for text going into code or data.
3. In Excel the problem is usually a number cell. A U+00A0 or U+200B inside a cell turns the number into text and your total silently goes wrong. After cleaning the characters out, remember to convert the column back to a number, or the cell stays text.
4. Treat quotes and dashes separately. Curly quotes and em dashes are correct typography in anything that will be published, and flattening them lowers quality. In a .json, .csv or source file they cause real errors, so flatten them there without hesitation.
5. Always replace confusables. A Cyrillic letter inside a Latin word is never something you want. It silently breaks search, sorting and matching.
6. Apply normalisation last, and pick the right one. NFC is lossless and safe almost always. NFKC is lossy: it folds fullwidth letters, ligatures and mathematical bold letters down to their plain equivalents. That is wonderful for search and data matching and destructive for deliberately formatted text.

Notes for developers: VS Code's editor.unicodeHighlight settings mark these characters in the editor and keep an allowed-characters and allowed-locales list so you are not drowned in warnings for writing your own language. In Python, unicodedata.normalize applies the same normalisation forms and str.isprintable() gives a quick check. In Notepad++, Show All Characters in the View menu displays the same characters in place. For text going into a Git repository the best place to catch this is before the commit; once it is in, it is in the history.

After every run, read the per-category receipt and the before and after comparison. If the difference is much larger than you expected, one of the options needs turning off. And every clean can be undone: the undo button does not disappear on a timer, it stays for as long as the page is open.

Method and Limits

What is detected: zero width and invisible characters, the Unicode tag block, variation selectors, bidirectional controls and whether they balance, unusual spaces, C0 and C1 control characters, line and paragraph separators, the replacement character, fullwidth forms, ligatures, mathematical alphanumeric symbols, combining mark stacking, sequences that are not in NFC, and non-Latin characters placed inside otherwise Latin words. Hidden payloads are decoded under four schemes.

What is not detected: authorship. Style. Whether a text was copied. And most importantly, a statistical watermark. A watermark of the kind Anthropic describes adds no character to the text at all; it biases the distribution of the model's word choices. This tool cannot see it and no character level tool can. We write that down as an honest statement of the limit rather than as a shortcoming.

A note on the marking method: this tool does not put a stand-in glyph where an invisible character sits. That is precisely the reasoning of UTS #55 section 4.2: even if these characters are made visible, their normal effect on the text should be retained, as this can otherwise lead to misleading rendering. If you make a zero width character visible by substituting a space for it, what you are showing is no longer the user's text: it wraps differently and measures differently. So here the marker is drawn as a frame around the character instead. Source: UTS #55, Unicode Source Code Handling. Confusable handling follows UTS #39 and directional behaviour follows UAX #9.

Watermarking Is a Separate Layer

Everything this tool reports lives at the character level: something that is physically sitting in the text. Text watermarking has an entirely different layer to it. According to Anthropic's own support page, models launched on or after 2 August 2026 support machine-readable marking at launch, while marking for existing models is still in progress. So it would be wrong to say that all Claude output after that date is watermarked; the right question is when the model you used was released.

The same page says two more things worth knowing. Generated files carry signed provenance metadata following the C2PA standard, which is a separate layer from the statistical mark inside the text. Anthropic also says it is working to let users and third parties detect these marks, which means there is not yet an open verification tool anyone can pick up today.

The text mark is statistical: it adds no extra character at all, it biases the model's word choices according to a secret key. The detector on this page cannot see it, and no character based tool can. If you want the detail on how such a watermark is placed, what it proves and whether it can be stripped, that is covered in our write-up on Claude's text watermark. The article covers the statistical layer; this tool covers the character layer.