How to Read a Third-Party AI Humanizer Test

Read a published test twice. The first pass tells you what the reviewer concluded. The second asks which conclusions you could reach from the evidence printed on the page. In the Tom's Guide feature from August 2026, one finding is directly checkable: a rewriting tool turned "at least 15,000 years ago" into "centuries ago," and both sentences are printed. The judgements about rhythm and naturalness are different. You can agree with them, but the article gives no stated rule for applying that judgement to another file.

The article is I tested popular AI humanizers — and they made my writing much worse, by Amanda Caswell, published 21 August 2026. I checked the page on 28 August 2026. Every quotation attributed to the feature below comes from its rendered article; quotations in the HumanPen section are identified as first-party product-page text.

One thing belongs on the table before anything else. We sell a document rewriting tool, so we have a stake in how this category is discussed. Keep that interest in view. The count below uses paragraphs printed by another publication, which means you can redo it without trusting us.

The feature prints enough of its setup for a reader to inspect one before-and-after example.

• The source text was generated: the reviewer "had ChatGPT write a short essay about the domestication of dogs," and the intro to that essay is printed in full. It runs 65 words by a plain whitespace split.
• That one paragraph was run through rewriting tools, and three of the returned versions are printed in full: Grammarly's Humanizer, Rehumanize.io, and Ace.ai.
• Two detectors are named on the page, GPTZero and Pangram, and one verdict is reported: Pangram marked the Ace.ai output as AI-written.
• The article says "several" tools were tried and that the same problem showed up "with benchmark scores and version numbers when I ran the test on more technical content." Those additional runs are described but not printed.

So the visible corpus is four paragraphs: one input and three outputs, all on one topic and all in English. That is a small body of evidence, but it is inspectable. The page does not disclose when the runs happened, how long they took, or the settings used.

The article reports three problems, and they behave completely differently once you try to take them anywhere.

Detector outcomes are outside what this article is about, and I am not going to build anything on the third row. It is included to mark the evidence boundary: the page reports one named verdict, while the other runs behind the broader sentence are not printed. That sentence should not be turned into a rate.

Here is my rule, so you can disagree with it. A numeral token is a maximal run of digits with optional internal commas, found by the pattern `\d[\d,]*`. The corpus is the four paragraphs as printed on that page and nothing else. A numeral survives if the identical token appears somewhere in the matching output. I did not judge meaning; I matched strings.

Input: "genetic and archaeological evidence suggests that dogs descended from an ancient population of wolves at least 15,000 years ago." · Rehumanize.io output: "based on genetics and old discoveries, it looks like dogs came from an ancient wolf group centuries ago." The article's own line: "We went from 15,000 years to 'centuries.'"

The input paragraph contains two numeral tokens, `15,000` and `30,000`. Three printed outputs give six chances for those two tokens to come back, and five of the six did. The one that did not is `15,000` in the Rehumanize.io output, which is the drift the article names. The other two outputs returned both tokens. Sensitivity check on the same extracted paragraphs: a case-insensitive whole-word count of `dogs` returns two matches in each paragraph, so the check was reading all four rather than stalling on one.

Now the honest part about that number. Six is two numerals times three printed outputs, all derived from the one 65-word input shown on the page. It verifies one named example reported in an article with a publication date. It is nowhere near enough for a rate, a ranking, or an expectation about your own file. The line to carry out of the article is the reviewer's own: "you can't trust the output without checking it against the original line by line. Any time the tool might save quickly disappears."

"Centuries ago" is not a typo. It is grammatical, but the claim it makes is not the claim in the source sentence. A spelling check does not compare those claims. An exact before-and-after comparison does.

The page does not reveal how any of the three tools work internally, so it cannot tell us why this change happened. What the visible pair shows is narrower: a specific value became a broad time label while the sentence remained grammatical. The reviewer names benchmark scores and version numbers as two more examples and writes that "details like data are not interchangeable the way certain words are." In an academic document, the same comparison can cover sample sizes, p values, doses, statute and section numbers, dates, the words inside quotation marks, and the author-year pair inside a citation.

In this example, the direct way to catch the change is to compare the returned sentence with the source. If you want a broader map of the risks, what happens to citations, tables and equations in an AI humanizer covers the elements that need separate checks. If something has already come back wrong, AI Humanizer Ruined My Paper? Restore Citations and Formatting covers the recovery order.

A magazine feature is not a benchmark and never said it was, so none of this is a complaint. It is the list you should have in your head before you quote the piece at anyone, including at yourself.

• A rate. One paragraph, three printed outputs. There is no denominator here that supports "N% of tools do this."
• How another tool behaves. The visible before-and-after names three products. It cannot establish how a product not shown on the page behaves.
• What happens to a document. The four printed paragraphs contain no footnote, numbered table, cross-reference, or reference list. The feature mentions additional technical-content runs without printing them, so the visible corpus cannot answer a file-layer question.
• When the visible runs happened. 21 August 2026 is the feature's publication date. The page does not disclose the dates of the product runs, so it cannot pin the outputs to that day.
• What happens in your language. All four paragraphs are English.

What it does give you is evidence from a third-party publication rather than a product page: a printed before and after with a visible factual change. That is enough to build a check, not a leaderboard. For a separate method aimed at document-format claims and downloadable test data, see how to check an AI humanizer's "preserves your formatting" claim.

You can reproduce the count above without submitting text to any tool. This checks what the feature prints, not any unprinted run behind its broader verdict.

1. Open the feature and locate the four printed paragraphs: the dog-domestication input and the Grammarly, Rehumanize.io, and Ace.ai outputs.
2. Extract the source numeral tokens with the stated rule, a maximal run of digits with optional internal commas. The input should give `15,000` and `30,000`.
3. Check each output for those exact strings. Record present or absent in a two-column grid. That creates six cells rather than a percentage.
4. Keep unprinted claims in a separate column. The technical-content runs, product settings, run dates, and detector values are reported by the feature but cannot be reconstructed from the visible paragraphs.

Your grid should contain five present cells and one absent cell. If it does not, compare the paragraph anchors and token rule before drawing a conclusion. To test a document of your own, use a separate file-level protocol: how to check an AI humanizer's "preserves your formatting" claim covers a deliberately difficult sample, and how to review a humanized Word document before submission covers the returned file.

Since I declared the interest at the top, here is the first-party part, kept to what our own page says. HumanPen takes the file rather than a text box, and the scope is something you set before anything runs: you can add passages directly or import a Turnitin or iThenticate report, and the page states that a paragraph is the smallest unit the engine rewrites, so a selection covering part of one "is expanded to the full paragraph and shown that way for you to confirm. Everything else is left untouched." The stated aim for what is inside the scope is to "preserve meaning, structure, terminology, citations, layout, and styles while rewriting only the necessary language." Eligible results can continue lowering AI for free.

That is a description of where a boundary sits, not a claim about what comes back inside it. Our own FAQ ends the relevant answer with "Review complex documents after download," and I would not want that line removed, because this whole article is an argument for it.

Nothing in a workflow removes step four above. A smaller scope means a shorter list of paragraphs to compare, which is a real saving when the alternative is a whole thesis. It is not a reason to skip the comparison on the paragraphs that were in scope.

Did you verify the whole Tom's Guide test? No. I recounted the visible before-and-after and found the stated `15,000` to "centuries" change. The page does not print the other technical runs, settings, dates, or detector values, so this article does not audit those parts of the feature.

Why not simply repeat the reviewer's overall verdict as your own? Because the visible input is a generated essay intro of 65 words with no citations, table, or reference list, while the feature also mentions technical runs it does not print. You can independently check the printed factual change. The broader verdict remains the reviewer's account of a larger, partly undisclosed set of runs.

Does this mean numbers always get changed? No. Five of the six numeral returns on the page came back intact. The visible example establishes that this kind of change occurred once and that an exact comparison catches it. It does not establish whether a normal read would catch it, or whether the problem is common or rare.

Where do I start if I want to test my own file? Use the separate formatting-preservation protocol linked above. It already covers building a deliberately difficult sample and comparing the returned artifact, while this page stays with reconstructing the evidence printed in one published feature.

What should I ask a vendor after reading a test like this? Ask for a before and after built from material like yours, then separate what the example visibly proves from what the vendor says about it. If a count appears, ask what was counted, what the denominator was, and which rule produced the number.