Invisible Character Detector

Text you paste out of a chat window, a PDF or Word is almost never plain text. It carries typographic punctuation, spaces that are not spaces, and occasionally something genuinely invisible. This page explains what is in there, which of it matters, and what the honest answer is to the question most people arrive with: does any of it prove the text came from an AI.

What AI output really contains

Run a paragraph from ChatGPT, Claude or Gemini through the detector and you will usually see the same short list.

None of this is a marker anyone put there deliberately. Part of it is the model reproducing the punctuation of the published prose it learned from, part of it is the interface: copying from a rendered chat bubble means copying HTML, and HTML gives you typographic characters. The same happens when you copy from a news site or a Google Doc.

What it does do is break the next step. A curly apostrophe in a code block is a syntax error. A non-breaking space in a spreadsheet column means the number stays text. A soft hyphen in a product name means the search for it returns nothing. That is the reason to check and clean, and it applies whether a person or a model wrote the sentence.

How to read the report

Paste on the left, read on the right. Cleaning is on by default, so the copy and download buttons already hand you the fixed text.

1. Findings. One entry per distinct character, sorted by severity, each naming the character, counting it, explaining what it does and listing the first positions as line and column.
2. Annotated text. Your text with every flagged character replaced by a chip showing its codepoint. This is the view that answers where exactly the thing sits.
3. Cleaned text. The version to paste onward.

The four numbers underneath: characters is the real codepoint count, which differs from what String.length reports in JavaScript for anything above the basic plane. UTF-8 bytes is what a database column with a byte limit counts. Invisible counts only what renders as nothing, and flagged counts everything the report picked up, visible lookalikes included.

--all-non-ascii

Highlights ordinary non-ASCII characters as well. Use it when something has to be pure ASCII, a slug, a filename, a database identifier, and you want to see every character that is not.

The character classes

Two are treated gently on purpose. A zero-width joiner between two emoji is doing its job, so it is reported as information and survives cleaning. Variation selectors are the same case: they decide whether a symbol renders as text or as an emoji, and stripping them changes what people see.

This is not an AI detector, and neither is anything else that counts characters

The question comes up constantly, so here is the straight answer. Finding an em dash, a curly quote or a zero-width space tells you the text passed through something that produces typographic output. That set includes every chat interface, but also Word, Google Docs, every CMS editor, most email clients and any copy out of a browser. A paragraph a person typed in Word and a paragraph a model generated look the same under a codepoint inspection.

Nor is there a hidden marker to find. The published research on text watermarking works by nudging which tokens a model selects, so the signal lives in word choice and is recoverable only with the key that produced it. It inserts no characters and would not show up in a report like this one. No major vendor has shipped a character-level watermark, and if one ever did, stripping it would be one regular expression away, which is precisely why nobody builds it that way.

Use the report for what it is good at, which is finding the characters that are about to break your import, your build or your search index. It is not evidence of authorship, and we would not present it as such.

Tag characters and bidi overrides

Two classes are worth more than a shrug when they show up.

Tag characters are the block from U+E0000 to U+E007F, an invisible one-to-one mirror of ASCII. They render as nothing, survive copy and paste, and arrive intact at anything that reads the raw string, which today includes language models. A block of them appended to an ordinary sentence is a working prompt injection: the human sees a support request, the model reads an instruction. The report collapses a whole block into one finding and decodes it back to ASCII, so you get the hidden sentence rather than a list of eighty codepoints. Nothing inserts these by accident, so treat a finding as deliberate, and filter the range at the input boundary of anything that feeds a model.

Bidirectional overrides tell the renderer to display a run of text right to left. In Arabic or Hebrew that is correct behaviour. In a source file it means the reviewer and the compiler see different programs, which is the Trojan Source attack from 2021. If the report flags U+202E in something you are about to merge, stop and read the file with the characters made visible.

Lookalikes and mixed scripts

Unicode contains dozens of characters that render like a Latin letter in most fonts. Cyrillic has a whole set of them because the alphabets share ancestry: а е о р с у х are visually identical to a e o p c y x and completely different codepoints. Greek adds ο ν α, and the fullwidth forms from U+FF01 give you a second ASCII. The full catalogue is Unicode's own confusables data in UTS #39, which is what browsers and registries check domain names against.

The detector only flags these inside a word that genuinely mixes alphabets. A Cyrillic о in a Cyrillic word is a letter; the same character inside administrator is a spoofing attempt. Most tools skip that test and flag every Cyrillic character they see, which makes them useless on anything but English. Where it matters: lookalike domains, package names that pass a review by eye, a second account called admin, and copied shell commands that fail with "command not found" for no visible reason.

The rule has one blind spot worth knowing. A word written entirely in lookalikes, with no Latin left to mix with, does not trigger it. Switch on --all-non-ascii when you are checking something that must be ASCII and want no doubt at all.

What --clean actually does

Cleaning is not "delete everything unusual". Each class is handled the way you would want it handled:

The replacement character is deliberately left in. Removing it would hide the fact that the text went through a broken decode, and the fix for that is upstream, at the point where the bytes were read with the wrong encoding. If the report shows U+FFFD, do not clean the text, go and find the original bytes.

Finding them in a codebase

One string at a time is fine for debugging. For a repository, use tools that scan:

• grep -rPn "[\x{200B}-\x{200F}\x{202A}-\x{202E}\x{FEFF}]" . finds the zero-width and bidi set. GNU grep with PCRE, so on macOS install it or use rg with the same pattern.
• VS Code has highlighted invisible and ambiguous characters since 1.63 through editor.unicodeHighlight. It is on by default and worth leaving on.
• ESLint has no-irregular-whitespace, which covers the space classes in JavaScript source but not identifiers or string content.
• A pre-commit hook running the same grep costs nothing and catches the pasted snippet before it reaches a review.

For data rather than code, fix it at the boundary. Normalise to NFC and strip the format and control categories when input arrives, not when a comparison fails three services later. The guide on invisible Unicode characters goes through the attack history in more detail, and if your problem is mangled accented letters rather than invisible ones, the mojibake explainer is the one you want.

Hunting invisible characters