A Copilot humanizer is the same tool as any other humanizer, and we are going to say that plainly rather than invent a Copilot-specific engine. There is no per-model code path here: the rewriter takes English text and works on its rhythm and phrasing, whether that text came from Microsoft 365 Copilot, GitHub Copilot, ChatGPT or Claude.
What is Copilot-specific is the kind of text you are pasting in. Copilot is used inside Word, Outlook and Teams, which means the drafts people want rewritten are mostly work email, internal documents and documentation rather than essays. That changes what matters: not detector scores, but whether the rewrite still says what you need it to say to a colleague.
Not a mystery, and worth understanding before you decide a rewrite is the fix.
Copilot is a large language model picking the statistically safest next token, the same as every other assistant, so it leaves the same fingerprint: sentences that cluster around a similar length, transitions that land in predictable places, and a vocabulary pulled toward the middle of the distribution.
What makes Copilot output distinctive in practice is context rather than architecture. It is drafting into business documents, so it produces a lot of scaffolding: "I hope this email finds you well", "In order to ensure", "Please don't hesitate to reach out". Those aren't model tells so much as business-register filler that the model reproduces heavily because its training data is full of it.
That is good news for the rewrite, because business scaffolding carries almost no meaning. Cutting it is nearly free. It is also why the Copilot case is lower risk than the academic one: an internal update has no citations to break.
The academic failure modes mostly don't apply here. The ones that do are different and less discussed.
Commitments and dates. A rewrite that smooths "we'll deliver by 14 November" into "we aim to deliver in mid-November" has changed a commitment into an aspiration. In an internal update that's a real difference, and nobody reading the prose will notice it happened.
Hedges, in both directions. Copilot hedges heavily. Stripping the hedging tightens the writing and can also turn a cautious internal assessment into a firm claim you didn't intend to make.
Named figures and metrics. Digits survive; units and comparatives don't reliably. Up 4 percentage points and up 4 percent are different numbers.
Technical terms in documentation. If you are rewriting README or API prose from GitHub Copilot, terms of art are the exposure, exactly as in legal and academic writing. The general check applies.
Light, Balanced and Maximum. Use Light wherever the wording is load-bearing: it varies sentence rhythm and cuts connective filler and leaves your vocabulary alone. Balanced edits phrasing more broadly. Maximum replaces most of the wording and is a paid mode; the free tier covers Light and Balanced per our published plans. The check is in humanizing without changing meaning.
Work a paragraph at a time. 3 rewrites a day at up to 300 words with no account, or 260 words per rewrite on a free account, which suits this use case well because work documents are short.
Then read the pair and check three things: did a date or commitment change, did a hedge flip, did a number’s unit change. If none did and the prose reads better, keep it.
We score before and after with our own detector, labelled as ours, and highlight the words that changed. For a work email the score is mostly beside the point; the diff is the useful part. Current plans are on the pricing page.
If the document came from Copilot inside Word, see the Word page for the formatting and version-history caveats, which matter more than the score.
Not in any meaningful technical sense, and we will not claim one. There is no per-model code path in our rewriter: it takes English text and works on rhythm and phrasing regardless of which assistant produced it. What is genuinely Copilot-specific is the type of document, since Copilot is used inside Word, Outlook and Teams, so the texts people want rewritten are work email and internal documents rather than essays.
Because it reproduces business-register scaffolding heavily: openers like "I hope this email finds you well", constructions like "in order to ensure", and closers like "please do not hesitate to reach out". Combined with the uniform sentence length every language model produces, that is what reads as machine-written. Most of that scaffolding carries no meaning, so cutting it is close to free.
Different things from academic writing. The real exposures are commitments and dates, where "we will deliver by 14 November" can become "we aim to deliver in mid-November" and quietly change an obligation; hedges, which Copilot overuses and a rewrite may strip or flip; and units on metrics, where percentage points and percent are not interchangeable. Read for those three rather than for style.
Yes, with the same caveat that applies to any technical writing: terms of art look like ordinary words and are the first thing a rewrite reaches for. If you are rewriting README or API prose, keep a short list of the terms that must not change and search the output for each one afterwards. Use the lightest mode for anything a developer will rely on.
Detectors read statistical properties rather than identifying a vendor, so no honest tool can tell you which assistant produced a passage. Ours scores how machine-like the text reads and labels the reading as ours; it does not name a model and we would not trust a product that claimed to. For work documents the score matters much less than whether the text says what you need it to say.
Balanced is usually right for work email and internal documents, where the exact wording is not load-bearing and the scaffolding is the problem. Use Light for documentation, anything with metrics in it, or anything containing a commitment. Maximum replaces most of the phrasing and is a paid mode; it is more than this use case needs.
3 rewrites a day at up to 300 words each with no account, or 260 words per rewrite on a free account in Light and Balanced modes. Work documents are usually short, so that covers the use case better than it covers a dissertation. Scoring costs nothing extra, though for an internal email the diff is more useful than the number.
Score a Copilot draft before it goes out.
See the detector →Formatting, Track Changes and version history caveats.
Read the guide →The email case specifically, worked through.
See the guide →The general check: what drifts first in a rewrite.
Read the method →The full tool, scored before and after.
See the tool →What our score cannot tell you, including which model wrote it.
See the limits →Rewrite a paragraph of Copilot output and read exactly what changed, especially the dates and the numbers. 3 scans a day at up to 1,000 words, no account.