DeepSeek invisible character detector

The DeepSeek invisible character detector is a language model reading your text on our server and writing up what it notices. That is a different instrument from what almost everything else on this search term offers. Competing pages run a fixed list of codepoints against your string in JavaScript and hand back a table. This route sends the text away, has a model read it, and returns prose.

Each instrument has a domain where it is the right one. A fixed-list scan is exhaustive within its list and blind outside it. A model is exhaustive nowhere, but it reads context: it can tell you the spacing around your dashes is inconsistent, that a paragraph carries three different apostrophes, or that a block of markdown looks like it passed through a converter. Neither result substitutes for the other, and a page that blurs them is selling certainty it does not have.

The procedure is short. The judgement is in step three.

Step 1

Capture the text straight from the DeepSeek chat. Every application you paste through contributes characters of its own, so a later copy tells you about your toolchain rather than about the model.

Step 2

Run the check, within 1 to 12,000 characters. The ceiling is per run, counted after surrounding whitespace is trimmed.

Step 3

Read the findings as hypotheses, not as an inventory. Confirm anything that matters with the browser scanner, which returns counts rather than descriptions.

It is worth being precise about the failure modes, because they run in opposite directions and knowing which you are exposed to changes how you use the result.

The model can miss

A zero-width space is genuinely invisible in the token stream the model sees. Absence of a finding is not evidence of a clean string.

The model can over-report

Asked what is hidden in a text, a model will sometimes produce a plausible answer rather than an observed one.

The scan cannot miss, inside its list

Fourteen codepoints, matched character by character. Every occurrence is found and counted.

The scan is blind outside its list

A character not among the 14 is not detected at all, and a clean result means clean of those 14 rather than clean.

Only one of them explains

The scan tells you what is present. Only the model can tell you a run of characters looks like a paste from a PDF.

The deterministic engine behind our watermark and zero-width routes holds exactly 14 entries. Six are removed outright: the zero-width space U+200B, the zero-width non-joiner U+200C, the zero-width joiner U+200D, the word joiner U+2060, the byte-order mark U+FEFF and the soft hyphen U+00AD. Five more are the directional controls U+202A to U+202E, also removed. The remaining three, the no-break space U+00A0, the narrow no-break space U+202F and the hair space U+200A, are substituted with an ordinary space, because they occupy the position of a word break and deleting them would concatenate words.

Fourteen is a deliberately smaller claim than the field makes. Pages read while researching this route between them cover tag characters U+E0000 to U+E007F, variation selectors U+FE00 to U+FE0F, the marks U+200E and U+200F, the isolates U+2066 to U+2069, the em space U+2003 and the ideographic space U+3000. None are in our engine. The number here is the number in the source file, and what we do not handle is named rather than quietly omitted.

The cost is never the character. It is the interval between the failure and the diagnosis, and that interval is long precisely because the cause draws no pixels. A developer bisects a build for an hour before checking the bytes. An editor rewrites a headline three times before someone notices the slug.

The failure modes are stable across contexts. Equality comparisons fail on strings that render identically. Parsers reject documents on the first byte. Character counts disagree with what the reader sees, so limit-enforced fields refuse text that appears to fit. Search and find-and-replace pass over the line you are looking at. In every case the diagnostic instinct is to suspect the visible thing you changed most recently, which is the one thing that is not responsible.

Five runs per rolling 24 hours, and 1 to 12,000 characters per run. The window rolls rather than resetting at a fixed hour, so capacity returns 24 hours after each run. No account, no email capture, no paid tier behind the count.

For calibration against the field: two of the tools checked for this route advertise no limits at all, which they can do because their work happens in your browser. A third, which meters like we do, publishes three checks a day at 1,000 characters for guests and ten a day at 3,000 once signed in. Our ceiling is four times its signed-in tier, with no sign-in. That is the trade: a server reading gives interpretation and costs an allowance, and the browser routes give exhaustiveness within 14 codepoints and cost nothing.

Two questions arrive together and both deserve a flat answer. There is no evidence that DeepSeek embeds a deliberate marker in its output. The characters people find are consistent with ordinary causes: generation, markdown rendering, and the transfer path out of the chat interface. The same characters appear in text copied from PDFs and web pages, which is what you expect from artefacts rather than a signature.

The second question is whether removing them changes an AI detector's verdict. We make no claim, and a page that did would be claiming knowledge of a third party's model. Detection tools report signals rather than proof of authorship, and we are not affiliated with any of them.

The reading is most useful when you do not yet know what you are looking for. Text that behaves oddly and you cannot say why, output that came through several applications, or a body of DeepSeek prose you want characterised before committing to a clean-up policy across a hundred documents.

When you already know the question, the deterministic route is the better instrument, and it is on this site rather than somewhere else. Ask for a reading when you need a description, a scan when you need a number.