Skip to content

Editorial standards

Methodology

This page exists so the claims elsewhere on the site can be checked. It covers who publishes Simple Unmark, how provider claims are sourced and dated, what we test, and — the part most tools in this category omit — what we cannot measure and therefore refuse to claim.

Last updated
Provider status verified
Published pages
6 tools · 9 guides

Who publishes this

Simple Unmark is an independent text-only tool for removing invisible Unicode artifacts and reducing statistical text watermark signals. It is operated as a small commercial product, funded by credit purchases rather than by advertising or affiliate links to the detectors and providers it writes about.

We have no commercial relationship with Google, OpenAI or Anthropic, and no access to any provider's private watermark keys or detectors. Where that limits what we can prove, the limitation is stated on the page rather than papered over.

How provider claims are sourced

Every provider status claim is held in one registry that feeds the provider pages, the status tracker and this page. A claim carries a confidence level and the date a person last re-read its sources.

  • "Documented" requires a first-party page from the provider itself. Press coverage never promotes a claim to documented, however extensive.
  • "Reported" means credible independent coverage exists without first-party confirmation, and the page says so in those words.
  • "Unverified" means neither, and we would rather publish that than imply certainty.
  • Provider status is reviewed monthly, and within 72 hours of a major announcement.
  • When a provider's documentation contradicts something we published, we change the page and the date rather than quietly leaving both up.

What we test on the deterministic layer

The character layer is exactly testable, so it is where we make exact claims. The full set of code points we remove or normalise is published as a coverage table on the invisible character remover, and the same character classes are used by the browser-side scanner and the server pass, from one shared module, so the preview cannot disagree with the result.

That layer is covered by unit tests, including cases that must not change: zero-width joiners and non-joiners are preserved, because deleting them corrupts emoji sequences and text in scripts such as Arabic, Persian, Hindi and Malayalam. A cleaner that damages legitimate multilingual text to look thorough is a worse tool, not a stronger one.

What we cannot measure on the statistical layer

We cannot measure watermark removal, and we will not publish a number that implies we can. Detecting a statistical text watermark requires the provider's key. Google publishes its approach and a reference implementation but no general detector for arbitrary text; Anthropic has said a detection API is coming but had not released one publicly at our last check.

So our claim is bounded deliberately: we replace the token-choice pattern that carries the signal, which is the change the providers themselves describe as degrading detection. We do not claim a score, a percentage, or that any text is undetectable.

  • We do not claim guaranteed removal, or that output is undetectable.
  • We do not claim to defeat named detectors or institutional policies.
  • We do not describe rewritten output as human-written.
  • We do not present invisible characters as proof that text is AI-generated.
  • We do not publish benchmark numbers we cannot reproduce from a stated method.

What we would publish if a detector became available

If a provider ships a public detection API, the honest version of this product's central claim becomes measurable, and we intend to measure it rather than keep describing it. The test we would run is specified in advance so the result cannot be framed after the fact.

  • A fixture set of provider-generated passages across lengths and genres, released publicly so anyone can rerun the test.
  • Detector score before and after cleaning, reported as a distribution rather than a single figure.
  • Semantic similarity and factual-consistency checks on the same pairs, because a rewrite that loses meaning is a failure even if the score drops.
  • Failure cases and the conditions that produce them, including short and highly factual text where we expect the weakest result.
  • Latency, token use and cost per request, so the operating claims are as checkable as the quality ones.

Privacy in the measurement itself

Analytics never receives submitted text, cleaned output, or any fragment of either. Product events carry only a page cluster, a coarse word-count band, an authentication state and a success or failure category — word counts are bucketed precisely so that no property can approximate the content of a request.

Request records in our own database store counts, status, timings and cost rather than text. The deterministic inspector goes further and sends nothing at all: it runs in your browser. Details are in the privacy policy.

Corrections

If something here is wrong, we would rather fix it than defend it. Corrections to technical or provider claims go to [email protected], and a material correction updates the page's visible date. We do not bump dates for cosmetic edits, because a date that moves for no reason is worth nothing to a reader.

Current coverage at a glance

Code points covered
44 named, plus the U+E0000–U+E007F tag range
Providers tracked
3, each with a verification date
Measured removal claims
None — no public detector exists to measure against

Every primary reference used on this site

Competitor pages are not cited as technical sources. They are evidence of how a market positions itself, not of how watermarking works. See the provider status tracker for the current dated claims.