Watermarks stop depending on the tokenizer: defined on UTF-8 bytes, detection holds when the tokenizer is swapped
Synopsis
Detecting a watermark in large-model text used to require the generating side's tokenizer or semantic embedding pipeline, which the text itself does not reveal, so text of unknown origin was hard to verify. ByteMark defines its signal on the UTF-8 byte stream of the published text; participating models embed it under one public specification and key, and a verifier needs only the text and the key. In experiments, replacing the detector's tokenizer or embedding model sharply degraded token-level and sentence-level baselines, while ByteMark's detection rate was unchanged, and it stayed detectable through a relay of models and after participating rewriters re-embedded the watermark.
Interpretation
Watermark detection can rest only on the published text's bytes, the key, and a public specification, without knowing which tokenizer or embedding model produced the text. Token-level watermarks define their signal on token IDs and sentence-level ones in a semantic embedding space; the same text yields different token IDs and segmentations under different tokenizers, so the detector must hold the generator's representation. Holding generated text fixed and replacing only the detector's tokenizer, each token-level baseline detects with its own tokenizer but largely fails with a replacement, whereas ByteMark's detection rate is unchanged across three datasets.
One fixed detector follows the watermark across model boundaries in a single document and still detects it after participating models rewrite and re-embed. A token-level detector reads the whole text with one fixed tokenizer, so it finds signal only in the segment written with that tokenizer and stays near zero elsewhere. In a relay where Pythia-1.4B, Qwen2.5-1.5B, and OpenLLaMA-3B write successive C4 segments, ByteMark's local signal holds its level across all three segments with no visible change at either switch; under Parrot, DIPPER, and Mistral-7B-Instruct rewriting with re-embedding, AUROC is 0.9985, 0.9998, and 0.9888.
Generation overhead stays close to unwatermarked generation because each output token is sampled once. Sentence-level watermarks generate several candidates per retained sentence and discard the rest; SimMark generates 119.36 candidate tokens per final output token and SemStamp 35.38. On the same 50 C4 requests with OpenLLaMA-3B at batch size one, unwatermarked generation reaches 63.82 tokens/s and ByteMark 62.19 tokens/s (97.4% relative), while SemStamp reaches 1.73, k-SemStamp 6.17, SimMark 0.49, and AliMark 18.22 tokens/s.
Perspective
The scheme targets readers who must verify text of unknown origin, or a service acting for them: the verifier holds the text and the key, not the generating model or its components. Experiments cover C4, Wikipedia, and LFQA, with Pythia-1.4B, Qwen2.5-1.5B, and OpenLLaMA-3B as generators, 500 generation requests per condition and 1,000 human texts per domain for the token-level comparisons. Detection thresholds are calibrated on held-out human text at a 1% target exceedance rate. Implementation and evaluation code will be released as open source after cleanup.
Rewriting by a non-participating model changes the byte stream and can weaken the ByteMark signal, a robustness question shared with token-level watermarks; whether a fixed, public semantic representation could improve robustness to rewriting while preserving detection from text, key, and public specification alone remains open. Key secrecy is a precondition, and one key serving every participating model means wider deployment places it with more parties, so a lost key exposes every participant's watermark at once. A closed-form characterization of the document-level statistic under watermarking would need additional assumptions on the byte distribution and cross-step dependencies, and that analysis is outside the current scope.