What this AI text watermark detector examines
NoLLMWM’s browser detector examines the sequence of Unicode code points in the text you paste. It looks for a maintained set of nonprinting or direction-control characters that can carry formatting, accidental residue, or an intentionally hidden payload. Each finding includes a standard-style name, hexadecimal code point, and UTF-16 position so you can reproduce the observation with another technical tool. This is a deterministic inspection: the same string and the same rule set produce the same physical findings.
The detector does not infer authorship from vocabulary, sentence rhythm, perplexity, or writing style. Those signals belong to AI-likelihood classification and have different error modes. It also does not claim access to secret vendor watermark keys. Keeping these boundaries explicit makes a narrower detector more useful: a reported physical character is inspectable evidence, while an unavailable statistical decision stays unavailable rather than being replaced with a guess.
Read the four supported result states precisely
The physical scan has two mutually exclusive results. “Supported physical Unicode signal found” means at least one character from the documented inspection set exists in the submitted string. “No supported physical signal found” means none of those characters matched. The word supported matters: Unicode is extensive, and documents can encode information in mechanisms beyond the current list. Neither result identifies who inserted a character or why it is present.
Two additional states describe what the product cannot determine. “Statistical/vendor watermark unknown” means there is no local conclusion about keyed token patterns. “Vendor verification unavailable” means the application does not possess an official private verifier for the provider in question. These messages remain visible alongside the physical result so users do not accidentally convert a narrow observation into a universal claim.
Keep in mind: A physical finding is evidence of a code point, not evidence that a particular model generated the surrounding prose.
Why invisible characters need context
A zero-width space can divide words in a writing system that does not use ordinary spaces, or it can be an unwanted character inserted during copy and paste. A word joiner can intentionally prevent a line break. Bidirectional isolates keep mixed right-to-left and left-to-right passages from reordering surrounding content. Soft hyphens tell a renderer where a word may break. Unicode tags can form hidden payloads, but recognized tag sequences also participate in some emoji flags.
For that reason, detection and deletion are separate actions. NoLLMWM reports context-sensitive characters but does not preselect them. It preserves zero-width joiners, zero-width non-joiners, common variation selectors, and recognized emoji tag sequences where feasible. This does not make automated context perfect; it gives you a safer starting point and explains why a blanket character-stripping expression is inappropriate for multilingual production text.
Why statistical watermark detection is different
A statistical text watermark can be implemented by subtly biasing token selection during generation. A detector that knows the scheme may score whether the observed token sequence contains more favored choices than chance would predict. The calculation can depend on secret material, tokenizer details, prompt context, sample length, and thresholds. There may be no unusual Unicode and no metadata. The apparent content is the possible signal.
An independent website cannot reconstruct a private detector merely by reading plain text. Even published watermark research often distinguishes between an algorithm description and operational keys. Results can also weaken after edits, translation, quotation, or mixing output from multiple systems. NoLLMWM therefore declines to manufacture a green or red badge for this category. If a vendor provides a public verification API in the future, it would need a separately identified integration and evidence policy.
Do not substitute an AI detector score
AI detectors usually classify linguistic patterns learned from examples or derived from model probabilities. A high score says the classifier finds the passage similar to its machine-generated examples; it does not prove that a watermark is present. A low score says the passage does not strongly match that classifier; it does not prove human authorship. Short text, formulaic business writing, second-language writing, technical templates, and edited model output can all challenge such systems.
Calling that probability a “watermark score” obscures both the method and the uncertainty. NoLLMWM does not compute generic AI likelihood in its watermark interface. If you use a separate authorship classifier, record its name, version, threshold, language coverage, and known limitations. For consequential decisions, combine transparent evidence with human review and an appeal path instead of treating one opaque percentage as a verdict.
Verify a physical finding independently
You can cross-check a reported finding with a code editor that shows control characters, a Unicode-aware command-line utility, or a short program that prints code points. Use the exact original string; copying through another application may normalize or remove characters before comparison. UTF-16 positions are useful in browsers and JavaScript, while other tools may report Unicode scalar positions or byte offsets, so an index difference does not necessarily mean the character is absent.
After cleanup, scan again and compare the before-and-after strings in your own environment. Check emoji, multilingual names, URLs, inline code, and bidirectional fragments visually and semantically. If the source is a DOCX, PDF, HTML file, or image, remember that plain-text inspection does not cover file properties, embedded resources, revision history, C2PA manifests, EXIF, XMP, or pixel-level signals. Those require format-specific analysis outside this MVP.
- Preserve the original privately before editing.
- Confirm the code point with a second Unicode-aware tool when the result matters.
- Document any intentional control characters so a later editor does not remove them.
Choose the next action from the evidence
If the detector finds a clearly accidental zero-width character, a local selective cleanup may be all you need. If it finds a script-sensitive or bidirectional control, consult someone who understands the language and layout before removal. If it finds nothing physical and your concern is a rumored statistical watermark, decide whether an authorized rewrite is worth the cost and semantic risk. Rewriting can change token statistics but cannot be certified against an unavailable vendor verifier.
If your real question is authorship, provenance, or policy compliance, collect the evidence that answers that question directly: drafts, revision history, citations, prompts, contributor statements, content credentials, and institutional rules. A watermark detector is one narrow technical instrument. It should not be asked to settle ownership, truth, or intent on its own.