AI watermark detector, defined scope

A zero-width space is either in your text or it is not. That is a fact about the document, decidable exactly, with no confidence interval attached. Who or what put it there is a separate question that the fact does not answer, and no amount of scanning converts one into the other.

Most of this category collapses the two. A tool finds U+200B, reports it as an AI watermark, and the reader infers machine authorship from a character that a CMS, a PDF extractor, a translation memory or a careful typographer could equally have inserted. This detector reports presence and declines the inference, which is the whole reason its output looks less exciting than its competitors'.

The ambiguity is not pedantic. It determines which claims on a page are even possible.

Character-level marking

Invisible codepoints present in the byte stream. Detection is exact string matching. This is the mechanism handled here.

Statistical, token-level marking

A generator biases sampling among near-equivalent continuations so a keyed statistical test can later recover the signal from the wording itself. Detection requires the key and the test. Neither exists in this repository.

Signed provenance metadata

A cryptographic manifest bound to a generated file. It concerns files rather than pasted text, and reading it is a different operation entirely.

Every step runs locally. There is no request, therefore no allowance, no input ceiling and nothing to transmit.

Step 1

Paste the artefact unmodified. Any intermediate step through a plain-text buffer destroys the evidence, so a scan of retyped text is uninformative by construction.

Step 2

Read the per-codepoint counts rather than the total. One byte-order mark and forty zero-width spaces are different findings with different likely causes.

Step 3

Separate the character findings from the phrase findings. The first are facts about the encoding. The second are stylistic judgements offered with reasons, and they are arguable.

Fourteen entries: the zero-width space, non-joiner and joiner, the word joiner, the byte-order mark, the soft hyphen, the no-break space, the narrow no-break space, the hair space, and the five directional formatting controls from left-to-right embedding through right-to-left override.

Competing lists run to 34, 87 or beyond, and the additional entries are largely visible characters: em dashes, curly quotation marks, variation selectors. Including a visible glyph in a list of hidden characters inflates the headline number while destroying the category. Three of our fourteen resolve to a space rather than to nothing, because the no-break space, narrow no-break space and hair space occupy positions where deletion would concatenate adjacent words. That distinction is encoded per entry rather than applied uniformly.

The analysis is deterministic. The same input produces the same output every time, because the operation is a scan against a fixed set of codepoints and a fixed set of documented patterns. There is no model, no threshold and no sampling, so there is nothing for a probability to quantify.

A percentage would therefore be pure presentation. What comes back instead is the text partitioned into plain runs, marked characters and flagged phrases, plus a count for each hidden codepoint, totals for hidden characters and flagged phrases, and the word and character counts. Every figure is a count of something you can verify by looking.

Two decisions in the matcher are worth stating because they change what you see. Phrase patterns can overlap, and when they do the earliest match wins, with the longest preferred at equal starting position. So a passage is attributed to one pattern rather than counted three times, and the flagged phrase total is a count of distinct spans rather than of rule hits.

The second is a deliberate exception. A zero-width joiner between two pictographic characters is the mechanism that fuses several emoji into one glyph, so the matcher inspects the codepoints on either side and passes over joiners doing that job. Reporting them would be technically accurate and practically wrong, since removing them would break the emoji. Hidden characters found inside a flagged phrase also survive as their own markers rather than being absorbed into the highlight.

It performs no statistical test on token choice, so a token-level watermark embedded by a generator is invisible to it. The published position on the one vendor watermark known to be deployed is that no public tool reliably reads it, and that any tool claiming to detect that vendor's text is either inferring from style or overstating what it does. We are not making that claim.

It does not parse signed provenance metadata, which is a file-level operation on a file we never receive. It does not attribute text to a model, because the characters it finds carry no vendor identifier and the inference is unavailable in principle. It performs no similarity matching. And it makes no statement about intent: nothing here establishes that any vendor inserts these characters deliberately, and the simpler explanation, that a generator has no keyboard and so pays no cost for emitting one, requires no motive at all.

Essentially not. AI detection operates on lexical and structural properties of the prose, and invisible characters are not among the features those systems weigh. Vendors in the detection business state this directly, and we have no reason and no evidence to contradict them.

The defensible returns from cleaning are all mechanical: search and replace that matches, slugs that resolve, parsers that accept the file, wrapping that behaves, and character limits that reflect visible length. These are verifiable at your desk. A third party's verdict is not, and nothing on this site will be sold as influencing one.