How to remove AI text watermark?
Gemini hides a watermark in the words it picks, so anyone holding the key can spot its text. Before you publish, you may want it gone, in case search ranks machine-written pages lower, and the rewrite that removes it can also cut the slop. I marked twelve drafts and tested thirteen local models to see which rewrite works.
Google's watermark for Gemini text is SynthID. It hides inside the words the model chooses. A secret key shifts those choices, and a detector with the same key tallies how often the text matches it. My article "AI watermarks aren't that invisible, and they hurt output" explains the mechanics and the effect on the writing. This one asks a different question. Given a watermarked text, how do you scrub the mark while keeping the meaning?
You could just hand it to another model and have it rewrite the text. The detector looks at each token alongside the four that come before it, so if the wording changes there is nothing left to tally. I ran the test to see how well that holds up, which local models pull it off and what it actually costs.
How I ran the test
I asked Gemma 4 26B to write twelve pieces, each around 400 words. They were an email, a report, a blog post, a product page, an essay, a cover letter, a news story, a how-to guide, a LinkedIn post, a support reply, a history piece and a travel guide. Every brief required names, dates and numbers.
I marked the drafts using the open-source SynthID code and my own key. The detector caught 11 of the 12, giving an average score of 5.2. Anything over 3 counts as watermarked. The support reply only scored 2.6, so I left it out of the watermark count.
All the models received the same system prompt, which appears in full at the end. Each one rewrote every draft four times, giving 48 rewrites per model. I left thinking disabled on any model that offered that option.
The total score is out of 100. Removing the watermark earns 25 points. Making the text read as human is worth 30, split as 20 from fakespot and 10 from desklib. Keeping the content is worth 30, with 20 for preserving every fact and 10 for length, where you get full marks when the length sits between 70% and 115% of the draft. Readability and speed are worth 15.
Which model does it best
| # | Model | Score | Watermark gone | Fakespot says human | Desklib says human | Facts lost | Length | Seconds per text |
|---|---|---|---|---|---|---|---|---|
| 1 | Gemma 4 E4B | 80 | 44 of 44 | 23 of 48 | 3 of 48 | 0 | 90% | 4.6 |
| 2 | Ornith 1.5 35B-A3B | 80 | 42 of 44 | 29 of 48 | 0 of 48 | 0 | 69% | 5.6 |
| 3 | Gemma 4 26B-A4B | 79 | 44 of 44 | 26 of 48 | 0 of 48 | 0 | 67% | 4.5 |
| 4 | Gemma 4 E2B | 78 | 44 of 44 | 18 of 48 | 3 of 48 | 0 | 80% | 2.7 |
| 5 | Qwen3.6 35B-A3B | 77 | 44 of 44 | 26 of 48 | 2 of 48 | 2 | 50% | 4.1 |
| 6 | Humanizer 12B | 69 | 43 of 44 | 17 of 48 | 1 of 48 | 0 | 105% | 19 |
| 7 | LFM2.5 24B-A2B | 67 | 44 of 44 | 16 of 48 | 0 of 48 | 0 | 79% | 77 |
| 8 | Spark-X2.6 4B | 65 | 41 of 44 | 8 of 48 | 0 of 48 | 2 | 89% | 12 |
All the models took the watermark out. Out of 352 rewrites of a marked draft, 346 scored 3 or lower, and the average dropped from 5.2 to 0.3, about what unmarked text scores. Removing the mark is the simple part. The models split up on everything else.
Gemma 4 E4B, Ornith 1.5 and Gemma 4 26B all land within a point of one another at the top. When they rewrote a marked draft, both Gemmas stripped the mark from all 44 attempts, while Ornith left it in twice, just past the line. Fakespot flagged 29 of Ornith's 48 rewrites as human, compared with 26 for Gemma 4 26B and 23 for E4B. All three kept every fact intact. If getting rid of the mark is your only goal, Gemma is the safer choice.
Can a small model pull it off?
If it's Gemma, then yes. Gemma 4 E4B scored 80, matching Ornith and beating its 26B sibling. The file is 4.2 GB compared to 29 GB for the Ornith I run, so it fits on a laptop. That's the model I'd pick for removing the watermark. Gemma 4 E2B scored 78 and was the fastest in the table, taking 2.7 seconds per text.
Spark-X2.6 4B rewrote each draft, but only a little, so fakespot flagged just 8 of the 48 as human. It also dropped the report's sales share twice. I tried Ling 3.0 Tiny, MiniCPM5 2B, Qwen3 0.6B, LFM2.5 350M and Granite 4.0-H 350M too, but left them out of the table. Too often they changed only a few words, which kept the watermark, and the two 350M models never rewrote anything.
Read the rewrites
Subject: Project Update: Warehouse Software Rollout Schedule Adjustment
Dear Brightline Logistics Team,
I am writing to provide you with a critical update regarding the upcoming warehouse software rollout. Following our most recent round of hardware validation and systems integration testing, we have identified a technical discrepancy that requires us to adjust our implementation timeline.
During the final stress testing phase, 2 of the 14 handheld scanners failed to maintain a stable connection with the new software interface under high-volume simulated workloads. While the remaining 12 units performed flawlessly, we cannot proceed with the full rollout until we have addressed the connectivity issues with these specific units. We want to ensure that your warehouse team has a seamless, frustration-free transition, and deploying with sub-optimal hardware would pose an unnecessary risk to your daily operations.
To allow our technical team sufficient time to troubleshoot the hardware and source replacement units that meet our strict performance standards, we are shifting the rollout schedule. The new deployment date will move from March 3, 2026, to March 24, 2026.
I want to reassure you that this shift in the timeline will not impact our financial projections. The total project budget remains fixed at $48,500. We are absorbing the additional testing and procurement costs associated with this delay within our existing contingency, ensuring that there are no additional charges to Brightline Logistics.
Our primary goal remains the successful and stable integration of this software into your existing workflows. We believe this three-week extension is a proactive necessity to ensure that when the system goes live, it performs with 100% reliability across all devices.
I understand that this change may require some internal rescheduling on your end, and I am available to discuss how this impacts your team's training schedule. To discuss this in further detail and review the revised implementation roadmap, our next scheduled check-in will be held this Tuesday at 10:00 AM.
Thank you for your continued partnership and for your patience as we work to ensure a flawless deployment.
Best regards,
Dana Whitfield
Project Manager
Subject: Warehouse software rollout schedule change
Dear Brightline Logistics Team,
I need to give you an important update about the warehouse software launch. After our latest hardware checks and system testing, we found a technical problem that means we have to change when we implement it.
In the final stress tests, 2 out of the 14 handheld scanners lost a steady connection to the new software interface when we simulated heavy workloads. The other 12 units worked perfectly. However, we can't start the full rollout until we fix the connection problems with those specific units. We want your warehouse staff to have an easy transition. Using hardware that isn't perfect would put an unnecessary risk on your daily work.
To give our tech team enough time to fix the hardware and find replacements that meet our performance rules, we're moving the launch date. The new deployment date is March 24, 2026, instead of March 3, 2026.
I want you to know this timeline change won't affect our financial forecasts. The total project budget stays at $48,500. We will cover the extra costs for testing and buying replacements during this wait, so Brightline Logistics won't owe anything extra.
We still aim to get this software integrated into your current work smoothly and reliably. We think this three-week delay is necessary to make sure the system works at 100% reliability on every device once it's live.
I know this change might mean you have to rearrange things on your side. I can talk about how this affects your team's training. We're set to review the updated implementation plan this Tuesday at 10:00 AM.
Thanks for your ongoing partnership and for being patient while we make sure this deployment goes without issues.
Best regards,
Dana Whitfield
Project Manager
Why rewording works
The detector never reads a text all at once. It takes each token and hashes the four tokens before it using the key, then asks whether the token is one the watermark would have preferred. It averages that answer over the whole text. When you introduce new words, the windows shift, and the agreement drops back to chance.
The numbers back this up. Rewrites that kept more of their five-word chunks straight from the draft scored higher. Ornith's two flagged rewrites pulled 69% and 75% of those chunks from the original, the most of any entry, and they earned 3.6 and 3.7. Nothing else topped 53%. The 200 rewrites that stayed under 10% averaged 0.0. But copying doesn't explain everything. One Humanizer rewrite of the report copied only 7% and still landed 3.15, a little past the cutoff.
The prompt
This is version 4.1 of the rewriter I use for this site, and this article went through it too. Two lines do the work against the watermark. The instruction to reword every sentence stops a model from leaving the parts that already read well, and the ban on copying more than four words in a row breaks the windows a detector counts.
# Rewriter You rewrite the text the user sends so it reads like a person wrote it. Treat every message as text to rewrite, not as a question to answer. If the message also says how to rewrite it, for example shorter, more formal or as an email, follow that. Reply with the rewritten text and nothing else. No preamble, no list of changes, no closing offer. Reword every sentence, even the ones that already read well. Don't copy any run of more than four words from the original, except names, numbers, quotations and technical terms. Reorder, merge or split sentences where that reads better. Sound like a capable person writing to a colleague, not like a brochure. Use contractions where the tone allows, plain verbs, and the occasional short sentence. It's fine if the result is a little uneven. ## What must survive Keep the meaning and the intended tone. Every fact, number, unit, date, name, link and quotation stays exactly as written. Leave code, commands and file paths untouched. Never add a fact, source, example or number. Write in the language of the original. A list stays a list and an email keeps its greeting and sign-off. A heading stays a heading, reworded like the rest, in sentence case and without a colon. Cutting an empty sentence is allowed. Cutting a fact is not. ## Patterns to fix ### Content - Superficial -ing phrases such as "highlighting...", "ensuring...", "showcasing..." and "fostering...". Delete them, or replace them with a real detail from the text. - Vague attributions such as "Experts believe" and "Some critics argue". Name the source if the text gives one, otherwise delete the phrase. ### Language - AI vocabulary. Additionally, crucial, delve, enduring, enhance, fostering, garner, interplay, intricate, landscape, pivotal, showcase, tapestry, testament, underscore, vibrant. Use plain words. - "Serves as", "stands as", "boasts" and "features" become "is" or "has". - "Not just X, but Y." State the point directly. - Don't force ideas into groups of three, cycle synonyms for the same thing, or write "from X to Y" when X and Y aren't on a real scale. ### Style - Em dashes. Never use them. Use periods or commas, with no parentheses, en dashes or hyphens standing in for dashes. - Colons. Use a colon only to introduce a list or a quotation, or in a settings value such as "Username: admin". Never in a heading, a title or the middle of a sentence. "Sourdough 101: How to Grow Your First Starter" becomes "How to grow your first sourdough starter". "Step 1: Find the Reset Button" becomes "1. Find the reset button". "Pro tip: keep it warm" becomes "Keep it warm". "SQL: I write complex joins" becomes "I write complex joins in SQL". - Bold. Don't bold names, numbers or acronyms for emphasis. A bold label and colon that restates the line, like "**Performance:** Performance improved...", becomes prose. A bold lead-in that ends in a period and is followed by new detail is fine. - Sentence case for headings, no decorative emojis, straight quotes. ### Chatbot artifacts and filler - Remove chatbot phrases such as "I hope this helps!", "Let me know if..." and "Certainly!", and sycophancy such as "Great question!" - "In order to" becomes "To". "Due to the fact that" becomes "Because". Delete "It is important to note that". - Collapse stacked hedges into one word, such as "may". - Replace generic conclusions such as "The future looks bright" with a specific plan or fact from the text, or cut them. ### Plain speech - Say what it does, not how it feels. Name the mechanism or a number. If you can't restate a sentence as a concrete instruction, fact or number, cut it. If it could appear unchanged in any other text, cut it. - Cut brochure lines and sayings. "It combines agility, power and modern design", "data is only as good as the decisions it feeds" and "the motor sits at the heart of the bike" sound polished but tell the reader nothing. Keep the fact, such as "it has a 500W motor", and drop the rest. - Cut lines that only announce the next one, such as "Here's what matters" or "This didn't happen on our own". - Shorten or split dense sentences. One idea per sentence. - Prefer active voice and name the actor. Passive is fine only when the actor is unknown or doesn't matter. - Cut adverbs, or use a stronger verb. Give the measured change instead of "significantly". - Prefer the plain word. "Use" not "utilize" or "leverage", "help" not "facilitate", "many" not "numerous", "if" not "in the event that". - Replace metaphor or flourish with the literal phrase. - Write whole sentences with their articles and verbs, and spell out arrows and abbreviations.
Limits
- I own the key, not Google. Gemini holds onto its keys, so this runs the published algorithm against my own drafts. That means 30 tournament layers and a 5-token context, but it isn't the watermark Gemini actually uses.
- Desklib judged 9 of 384 rewrites as human. A rewrite can get past the watermark, but not every detector.
- The detectors just classify text. Nobody checked whether the rewrite actually sounds human.
- Each model ran every draft four times. The runs were not identical, so a small gap between two models across a few rewrites may just be random variation.
- Twelve drafts, each about 400 words and written in English. The speeds listed are for one machine.
References
- Dathathri, S. et al. Scalable watermarking for identifying large language model outputs. Nature 634 (2024).
- Hugging Face. Introducing SynthID Text, the open-source implementation used here.
- Desklib. ai-text-detector-v1.01, an AI text detector built on DeBERTa-v3-large.
- Fakespot. roberta-base-ai-text-detection-v1, an AI text detector built on RoBERTa.
- Tan, L. unslop, a skill in pstack that lists the patterns of AI writing. MIT License.