Best AI Text Watermark Detectors 2026
Compare four source-matched AI text watermark detectors, their real deployment costs, and the Claude, Gemini, and ChatGPT verification gaps in 2026.
- HHugging Face SynthID Text
- MMarkLLM
- Llm-watermarking
- Wwatermarks-remover
- AAnthropic Claude Watermark Detection API
- GGetGPT Text Watermark Scanner
- WWatermarkDetector.com
- PPhi-4 Mini Instruct
- Lllama.cpp
- AAnthropic

There is no public universal AI text watermark detector in 2026. For teams that control their own model, Hugging Face SynthID Text is the best production path, but its training recipe starts with 10,000 examples: one watermarked and one plain output per prompt turns that into 20,000 generation runs before deployment. For third-party Claude or Gemini text, the honest status on 16 August 2026 is unsupported.
The Short Answer: Source Access Decides the Winner
An AI text watermark is not a suspicious space, a funny dash, or a generic estimate that prose sounds machine-written. The systems worth buying or building around place a statistical signal in a model's word choices. Reading that signal requires a detector matched to the generator's watermark configuration, and often its secret key.
That distinction changes the buying decision. If you control the model and its generation settings, you can deploy a real detector. If a provider gives you an official verification API, you can call it. If neither is true, the answer is unsupported, not "human-written" and not "watermark-free."
Here is the ranking for software that can do useful work now. Prices were verified on 16 August 2026. All four have a $0 open-source software license, but none removes the cost of model inference, calibration, storage, engineering, or review.
Best overall: Hugging Face SynthID Text, but only for an organization that owns the generation path. Its implementation is the closest option here to production infrastructure, and its documentation is unusually clear about the training burden and failure modes.
Best for evaluation: MarkLLM. It gives a research or platform team one bench for comparing multiple schemes instead of confusing one detector's confidence score with universal truth.
Best simple baseline: lm-watermarking. It is narrower and older, which is useful when the job is to reproduce the KGW method with known settings rather than survey a large toolbox.
Best inspection companion: watermarks-remover. It is excellent at finding text-level artifacts and can invoke a same-config detector, but it cannot certify that a proprietary provider watermark is absent.
Anthropic's announced Claude detector may eventually be the right answer for Claude output. It is not ranked because the API, access terms, limits, and price have not been published. Google's public verification surfaces also do not currently accept pasted text, while OpenAI's public verifier currently covers images and audio rather than text. A procurement team should not fill those gaps with a consumer browser scanner.
How These AI Text Watermark Detectors Were Picked
The ranking uses five criteria that map to a real deployment decision.
- Evidence type: A watermark detector must look for an intentionally embedded signal. A classifier that merely predicts whether prose resembles AI writing belongs in a different category.
- Source match: The detector must say which generation configuration, key, tokenizer, or provider it can actually verify. A claim to identify every model without source access is a reason for caution.
- Deployability: A credible method needs a usable implementation, documented inputs, a detection path, and enough detail to reproduce its result.
- Robustness: The documentation must acknowledge short samples, factual text, code, paraphrasing, rewriting, translation, or other transformations that weaken the signal.
- Operational cost: An open-source license is not the budget. Generation runs, detector training, evaluation corpora, threshold calibration, key custody, logging, and human review all matter.
The first four tools passed because their scope is explicit and their limitations are inspectable. Consumer Unicode scanners appear later because they solve a narrower sanitation problem. Ordinary AI-writing classifiers were excluded because they infer style rather than read an embedded key. If that is the product you need, the separate guide to the best AI detectors in 2026 compares that category without pretending it is watermark verification.
All product, license, repository, version, and availability claims were checked against first-party pages on 16 August 2026. None of the active or high-value partner programs available for this roundup provides text-watermark verification, so no partner was inserted into the ranking. A commercially convenient inclusion would make the comparison less accurate.
1. Hugging Face SynthID Text: Best Production Path for Teams That Control Generation
Hugging Face SynthID Text is the strongest current choice when your organization owns the model-serving path and can watermark text at generation time. Google DeepMind and Hugging Face added the implementation in Transformers v4.46.0, pairing watermark generation with a trainable detector rather than offering a magical paste-in verdict. Hugging Face's implementation guide documents both sides of that system. The concrete use case is an enterprise model platform that needs to distinguish outputs from its own supported models across internal applications. The wall is just as concrete: it cannot identify arbitrary Claude, Gemini, or ChatGPT text when you do not have the matching configuration and training data.

The generation side adjusts token probabilities through a keyed watermarking configuration. Hugging Face recommends 20 to 30 unique random integers for the key and describes an n-gram length of 5 as a good default, with 2 as the minimum. Those values are not universal settings to copy into a detector after the fact. They are part of a configuration that must stay consistent from generation through detector training.
The detector side is where the apparently free tool becomes a project. Hugging Face recommends at least 10,000 examples, split between watermarked and unwatermarked outputs and then divided into training and test data. If the organization produces one marked and one plain answer for each prompt, that is 20,000 generation runs before detector training. The repository license remains $0; the model compute and staff time do not.
There is one useful scaling path. Models that share a tokenizer may share a watermark configuration and detector, but only if the detector's training data contains examples from every participating model. That can reduce the number of detector services an internal platform owns. It also means a model upgrade is not a paperwork change: it is a reason to add fresh samples and validate the detector again.
The failure modes should shape policy. Thorough rewriting or translation can sharply reduce confidence, and factual responses are harder to mark because the model has less freedom to choose among plausible words. A detector result therefore belongs beside source metadata, not in place of it. Use it to strengthen an audit trail, not to accuse an employee, student, contractor, or publisher on one score.
Best for: Product and platform teams that control text generation and can preserve the watermark configuration.
Standout: A production-oriented Transformers implementation with an explicit detector-training recipe.
Pricing: $0 Apache-2.0 software license, verified 16 August 2026; inference, training, storage, and engineering are extra.
Free trial: Not applicable; the implementation is open source.
- Pairs generation and detection in the same documented ecosystem.
- Gives concrete starting guidance for key count, n-gram length, and training-set scale.
- Can cover several same-tokenizer models with one detector when all models are represented in training.
- Documents rewrite, translation, and factual-text weaknesses instead of hiding them.
- Requires control of the generation configuration and detector data.
- Starts with a material calibration workload, not a one-click scan.
- Cannot verify proprietary provider text without the provider's matching key or interface.
- Detection confidence weakens on heavily transformed or constrained text.
A Practical SynthID Text Pilot
Choose one owned generation path
Start with one model, one tokenizer, and one narrow output type, such as customer-support drafts. Do not mix models or use cases until the baseline is understandable.
Freeze the watermark configuration
Create and protect the key, record the n-gram setting, and version the complete generation configuration. Detector results are meaningful only while that source configuration remains known.
Build paired examples
Use at least 10,000 representative prompts. Produce one marked and one plain output for each prompt, then split the resulting 20,000 runs into training and held-out test data.
Train and calibrate the detector
Train on the known classes, then choose an operating threshold against held-out text. Measure false positives on plain output and missed detections on marked output before attaching a policy consequence.
Challenge the result
Add short answers, factual passages, code-like text, paraphrases, and translations to the evaluation set. Record unsupported cases separately instead of forcing them into a binary verdict.
Version the whole chain
Store the source application, model, tokenizer, configuration version, detector version, and result together. Recalibrate after a model or watermark change.
Verdict: Pick Hugging Face SynthID Text when provenance is part of a generation system you own. Skip it when your only input is pasted text from an unknown provider.
2. MarkLLM: Best Evaluation Bench Before Choosing a Watermark
MarkLLM is the best evaluation environment for a research team deciding which watermark scheme can survive its actual content and robustness tests. The open-source project supports generation and detection across multiple approaches, including KGW and SynthID-Text, with separate pipelines for watermarked and unwatermarked material. Its practical use case is a platform group comparing methods on product-specific prompts before committing to one generation scheme. Its limit is fundamental: breadth across published methods does not give it the secret configuration for a vendor's private model.

MarkLLM lists 12 evaluation tools spanning detectability, robustness, and text quality. That matters because a detector can look impressive on clean, long samples while failing after the transformations ordinary workflows introduce. A legal drafting product, a support assistant, and a code assistant do not produce the same distribution of text. The right evaluation bench lets those differences decide the scheme rather than relying on one headline score.
The environment is built around Python 3.10 and PyTorch. As of 16 August 2026, the repository showed 1.0k GitHub stars, 176 commits, and a latest listed commit dated 10 July 2026. Those repository signals do not prove production reliability, but they do show a broader and more recently maintained research surface than several narrower implementations.
The best reason to choose MarkLLM is not that it supports the most names. It is that it can keep generation, attack, detection, and quality evaluation in one reproducible experiment. That makes it easier to answer the question a business actually has: which signal remains useful after the edits our workflow permits, at a false-positive rate our policy can tolerate?
Do not make MarkLLM the front door for arbitrary submitted documents. It should sit behind a controlled experiment or an owned generation system, where the watermark method and settings are known. Without that source match, its detector output cannot become a Claude, Gemini, or ChatGPT provenance verdict.
Best for: Research and platform teams comparing watermark schemes before production selection.
Standout: Twelve evaluation tools plus generation and detection pipelines across multiple methods.
Pricing: $0 Apache-2.0 software license, verified 16 August 2026; compute and integration are extra.
Free trial: Not applicable; the toolkit is open source.
- Compares multiple watermark families in one environment.
- Tests detectability, robustness, and text quality rather than one score alone.
- Includes both watermarked and unwatermarked detection pipelines.
- Showed recent repository activity in July 2026.
- Requires Python, PyTorch, model access, and research engineering.
- Can encourage broad experimentation before the policy use case is defined.
- Does not possess proprietary provider keys or turn unknown text into verified provenance.
- Production monitoring, access control, and incident workflow remain your responsibility.
Verdict: Choose MarkLLM before choosing a watermark, not as a universal detector after the text has already arrived.
3. lm-watermarking: Best Explainable KGW Baseline
lm-watermarking is the cleanest choice for a small research group that wants the official KGW implementation and a narrow, explainable baseline. The official repository integrates with Hugging Face Transformers generation and keeps the relationship between generation settings and detection settings visible. The concrete use case is reproducing a published watermark experiment before comparing newer schemes. The wall is configuration sensitivity: gamma, seeding, tokenizer, device, and other detector inputs must match generation, so unknown vendor text remains outside scope.

The repository's documented starting point uses gamma 0.25, delta 2.0, context width h=4, and selfhash. That recommendation is presented as the maintainers' understanding from August 2023, so treat it as a reproducible baseline rather than a current universal optimum. Its age is not automatically a defect. When a method is used as a control in an evaluation, stability and transparent assumptions can be more valuable than a long feature list.
Detection also requires discipline around repeated n-grams. The documentation says repeated n-grams should be ignored for valid p-values, and it warns that generation and detector settings must agree. Those details are exactly why copying a detector interface and feeding it anonymous text does not establish origin. The statistic only has meaning relative to the scheme that produced the text.
As of 16 August 2026, lm-watermarking carried an Apache-2.0 license, 694 GitHub stars, 16 commits, and a latest listed commit dated 17 September 2025. MarkLLM offers a wider evaluation suite and Hugging Face SynthID Text offers the stronger production path. lm-watermarking wins when the goal is to understand and reproduce KGW without introducing extra framework breadth.
Best for: Researchers and senior builders who need a transparent KGW control implementation.
Standout: The official implementation keeps matching generation and detector settings explicit.
Pricing: $0 Apache-2.0 software license, verified 16 August 2026; model and compute costs are extra.
Free trial: Not applicable; the implementation is open source.
- Provides the official implementation of the KGW watermarking papers.
- Offers a focused baseline that is easier to reason about than a multi-scheme bench.
- Integrates with the familiar Transformers generation interface.
- Documents settings needed for valid detection and p-value handling.
- Narrower than MarkLLM and less production-oriented than Hugging Face SynthID Text.
- Recommended baseline guidance dates to August 2023.
- Matching tokenizer, device, seeding, and generation settings creates operational fragility.
- Cannot verify a proprietary provider's watermark without its configuration.
Verdict: Use lm-watermarking when reproducibility is the job. Skip it when the job is multi-method evaluation, turnkey governance, or third-party provider verification.
4. watermarks-remover: Best Inspection Companion, Not Provider Proof
watermarks-remover is the best companion for inspecting the different artifacts people casually group under "AI watermarks." The open-source project can examine and clean invisible Unicode, metadata, and C2PA-related structures, then use a separate rewrite layer for statistical patterns. Its optional MarkLLM integration can detect KGW and SynthID marks when the same configuration is available. The project explicitly does not present that integration as an oracle for a proprietary vendor detector, and that caveat is the reason it belongs fourth rather than first.

The practical use case is an editorial, compliance, or security workflow that needs to inventory artifacts before text moves between systems. Invisible Unicode can create search, parsing, comparison, or formatting problems even when it is not an AI provenance mark. Metadata and C2PA structures are separate evidence layers again. One tool that makes those layers visible can improve text hygiene without claiming more than it knows.
The danger is semantic. A cleaned zero-width character does not remove Anthropic's statistical word-choice pattern, because Anthropic says its method adds no hidden characters. A rewrite may weaken a statistical signal, but without the provider's detector there is no way to certify that the signal is gone. "The file looks clean" and "the provider's detector will return negative" are different claims.
The repository had 11.1k GitHub stars, 1.2k forks, 87 commits, and a latest listed commit dated 15 August 2026 when verified on 16 August. That adoption makes it an important part of the buyer conversation, especially because removal interest can outpace detection infrastructure. Popularity still does not widen the evidence it can read.
Best for: Auditors and content operations teams separating Unicode, metadata, C2PA, and same-config statistical checks.
Standout: One inspection workflow for several artifact types, with an optional MarkLLM detector integration.
Pricing: $0 MIT software license, verified 16 August 2026; optional model and infrastructure costs are extra.
Free trial: Not applicable; the project is open source.
- Separates hidden-character sanitation from statistical watermark analysis.
- Covers Unicode, metadata, and C2PA-related inspection in one project.
- Can use MarkLLM for KGW or SynthID checks when the matching configuration exists.
- Showed substantial adoption and a current August 2026 repository update.
- Its name can invite a stronger provenance claim than the documentation supports.
- Rewriting may reduce a signal without proving the provider detector will return negative.
- Same-config detection still requires source knowledge.
- Cleaning an artifact can destroy useful evidence if the original is not preserved.
Verdict: Use watermarks-remover to inspect and sanitize known artifact classes. Do not use it to certify that unknown third-party text was never marked.
Anthropic's Claude Detector Is the Watchlist Leader, Not a Product Yet
Anthropic's Claude Watermark Detection API is the most important provider verifier to watch because it is tied to the key used by Claude's new text-marking system. Anthropic announced the capability on 14 August 2026 and says the detector API is forthcoming. It has not published implementation details, access terms, limits, or pricing. That makes it a credible direction, not something a buyer can deploy today.

Claude's method is a version of SynthID-Text. It puts a keyed statistical pattern into word choices, with no hidden characters, no extra tokens, and no embedded user or organization identity. Anthropic says the mark has negligible speed impact and adds no serving or usage price. Those generation economics are encouraging, but they are not the detector API's commercial terms.
Coverage is also specific. Anthropic's support guidance says Claude models launched in the EU on or after 2 August 2026 support marking at launch, while support for older models is in progress. Where supported, the mark can apply worldwide across Claude Platform and API, Claude, Claude Code, Claude Cowork, Claude Tag, and listed cloud partners. That breadth helps only if a downstream verifier can access the corresponding detection service.
The limits should be in every procurement note. Short samples are weak, factual passages and code carry less signal, and heavy editing, paraphrasing, translation, or a full rewrite can eliminate a detectable pattern. Even a positive result means Claude may have processed the text. It does not prove Claude originated the ideas or the first draft.
The business consequence is simple: preserve provider, model, version, timestamp, and source-application records now. Put watermark verification behind an adapter that can accept a provider response later. Do not purchase a generic Unicode scanner as a temporary Claude detector, because it reads a different kind of evidence.
Best for: Future verification of supported Claude output through Anthropic's own key and service.
Standout: A provider-controlled detector paired with Claude's keyed statistical watermark.
Pricing: Not published for the forthcoming detector API as of 16 August 2026.
Free trial: Not announced.
- Will use the provider's own detection key rather than infer origin from writing style.
- The announced mark adds no hidden characters or extra output tokens.
- Supported marking spans Claude products, the API, and listed cloud channels.
- Anthropic documents important interpretation and transformation limits.
- The detection API is not publicly available yet.
- Access, limits, implementation details, and detector pricing remain unpublished.
- Short, factual, code-heavy, translated, or heavily edited text can be difficult or impossible to verify.
- A positive signal indicates Claude processing, not sole authorship.
Verdict: Design for Anthropic's API, but do not budget it as an available control until access and pricing are live.
Who Should Pick What
A funded founder operating an owned model endpoint should start with Hugging Face SynthID Text. The watermark can be installed where text is generated, and the detector can be trained on the company's real output distribution. Budget the 20,000 paired runs and one narrow pilot before promising provenance across the product.
A mid-market CTO comparing methods should use MarkLLM first. Pick representative support, sales, policy, and code prompts, then evaluate detectability, robustness, and text quality together. The goal is not to crown a universal winner. It is to find the method whose failure mode fits the company's risk tolerance.
A small research group reproducing KGW should pick lm-watermarking. Its narrower scope makes assumptions visible and keeps the experiment explainable. Move to MarkLLM when the research question becomes comparative rather than reproductive.
An audit or content-operations lead inspecting mixed artifacts should use watermarks-remover as a companion. Preserve the original, inspect Unicode and metadata, and only run a statistical detector when the matching configuration is known. Report each evidence layer separately.
A buyer checking third-party Claude, Gemini, or ChatGPT text should not pick any of the four as a universal scanner. Wait for the appropriate provider verifier, request source records, or label the case unsupported. Anthropic's API is forthcoming, Google's public text verification is not exposed alongside its current media verification surfaces, and OpenAI's public verifier currently covers image and audio formats.
The choice flips on one question: do you control the generator or possess the provider's verification path? Everything else is feature comparison inside that boundary.

The Budget Line Is Calibration, Not the License
Every ranked tool starts at $0 for its software license. That is the least useful cost number in the decision.
Hugging Face's minimum training guidance creates the first real line item. Start with 10,000 representative prompts. Produce one marked and one plain output for each. The result is 20,000 generation runs, followed by detector training, held-out evaluation, threshold selection, and repeated tests after a model or configuration change.

Inference cost is only one part of that budget. Someone has to define representative prompts, keep keys and configurations versioned, store outputs, label the two classes, inspect failures, and decide what a detector result is allowed to trigger. If a positive score automatically blocks publication, payment, admission, or employment, threshold and appeal design become more important than repository popularity.
There are three states to preserve:
- Detected: The paired detector found a signal at the organization's chosen operating threshold.
- Not detected: The paired detector did not find a signal in a supported sample. Editing, length, content type, or model mismatch may still explain the result.
- Unsupported: No source-matched detector exists for the claimed generator, or the sample falls outside the detector's supported conditions.
Collapsing the last two states is the expensive mistake. "Not detected" is already narrower than "human-written." "Unsupported" means the system had no valid instrument for the question.
The broader governance design belongs beside your AI-generated content watermark policy. Embedded marks, disclosure labels, source logs, and content credentials solve different parts of the provenance problem. A robust workflow combines them rather than expecting one detector score to carry the whole case.
The Ones to Avoid as Provenance Proof
GetGPT Text Watermark Scanner is a useful free Unicode checker, but it is not a detector for Anthropic's keyed statistical mark. The browser tool scans more than 34 hidden or ambiguous Unicode characters, including U+200B, U+202F, U+2014, and U+2003, without requiring sign-up. That can catch formatting artifacts worth cleaning. It cannot read a signal that Anthropic says contains no hidden characters.

Use GetGPT when copied text behaves strangely in a CMS, diff, search index, or downstream parser. Do not use its clean result to claim that Claude, Gemini, ChatGPT, or a human wrote the text. The evidence categories do not match.
WatermarkDetector.com is another useful free browser-local Unicode scanner, with 26 character categories, unlimited stated use, and no public API. It is well suited to quick text-format QA when sensitive text should stay in the browser. It still lacks the provider key or generation configuration needed to verify a statistical model watermark.

Keep WatermarkDetector.com in the copy-hygiene toolbox, not the authorship tribunal. Its product scope is narrower than the assigned question, and the honest label prevents a useful tool from being misapplied.
Generic AI-writing classifiers belong outside the watermark ranking for the same reason. They estimate whether linguistic patterns resemble model output. A text watermark detector looks for a signal deliberately embedded by a known generation process. Both can produce a score, but the score answers a different question.
Google and OpenAI also need careful wording. Google says SynthID marks and identifies text generated in Gemini, yet its public Gemini verification flow and SynthID Detector portal currently list image, video, and audio verification rather than pasted text. OpenAI's public verifier similarly lists image and audio formats. Neither public surface turns a third-party Unicode scanner into an official text verifier.
Your Monday Move
Do not start Monday by buying a scanner. Start with an inventory.
- List every product and workflow that generates, edits, or receives AI-assisted text.
- Record the provider, model, version, source application, and whether your organization controls generation.
- Add one of three detector states: owned detector available, official provider verifier available, or unsupported.
- Choose one owned-model workflow for a narrow Hugging Face SynthID Text pilot, with paired marked and plain outputs.
- Preserve originals before any Unicode cleaning, metadata removal, paraphrasing, or translation.
- Put provider verification behind one internal adapter so Anthropic's forthcoming API can be added without rewriting the policy.
- Write the rule for what a positive, negative, and unsupported result can actually trigger.
The Monday outcome is not a universal detector contract. It is a provenance map that shows where evidence exists, where calibration money belongs, and where the organization must say "unknown."
Frequently Asked Questions
How to detect watermarks in AI text?
Use the detector paired with the generator's watermark key or configuration. If you control generation, train and calibrate the matching detector on marked and plain outputs. If a provider offers an official verifier, use that service. Without either path, a generic scan cannot verify the provider's statistical mark.
Does AI leave watermarks on text?
Some supported systems do. Google says SynthID marks text generated in Gemini, and newer supported Claude models use a version of SynthID-Text. Coverage is not universal, and short, factual, translated, or heavily edited text can carry too little detectable signal.
Does Claude AI watermark text?
Supported Claude models launched in the EU on or after 2 August 2026 mark generated text at launch, with older-model support still rolling out. The mark is a keyed statistical pattern in word choice, not a hidden-character trick. Anthropic's detection API is forthcoming.
How to check a ChatGPT watermark?
OpenAI's public verifier currently supports images and audio, not pasted text. A Unicode browser scanner can identify suspicious characters in copied text, but it cannot establish that ChatGPT generated the words.
Can ChatGPT remove watermarks?
A full rewrite can disrupt statistical word-choice patterns, but that does not prove human authorship or guarantee that a provider detector will return negative. Preserve the original and report what the available detector actually supports.
Get the AI Tools Map for Business Owners to separate deployable AI infrastructure from tools that only sound like it.
Aug 16, 2026







