AI Humanizer DOCX Test: Track Changes and Comments

In one HumanPen test on August 31, 2026, yes: one selected 133-word paragraph changed while one tracked insertion, one tracked deletion, one reviewer comment, one content control, one bookmark and REF field, and one table remained present in the returned DOCX. HumanPen publishes this article and ran the test on its own product. This is one file and one run, not a guarantee for every Word document.

We did not use a detector in this test. The question was narrower: when a specific paragraph is rewritten, what happens to the Word objects outside that paragraph?

We checked the file at three levels. First, we counted its internal Word structures. Next, we compared every part in the DOCX package. Then we rendered the input and output and compared the pages. One check was still unavailable: we could not manually open, save, close, and reopen the output in Microsoft Word because local computer-control permission was not available. That gap matters, and it stays open.

The input was a synthetic two-page document made for this experiment. It contained no student paper, research data, or client material. Page 1 held the Word objects we wanted to count. Page 2 held one ordinary paragraph marked as the only rewrite scope.

The sentinels included `TRACK-ANCHOR-23`, `COMMENT-ANCHOR-47`, `CONTROL-TABLE-91`, `37.5%`, and `12.40 mg`. The bookmark label appeared twice by design: once at the bookmark and once as the displayed REF result.

There is an important boundary in that setup. Every instrumented object was outside the selected paragraph. The run tests preservation outside a confirmed rewrite scope. It does not tell us what would happen if a comment anchor, tracked change, field, or content control sat inside the paragraph being rewritten.

The untouched input was 40,191 bytes with SHA-256:

`cccbac04cf9742037b16c453b54ae3c8a2300e7491ba31a213566c979c6fe4f1`

That hash identifies the exact input used in this run. A different file, even one that looks the same in Word, would produce a different hash.

We uploaded the DOCX to HumanPen at 20:00 China Standard Time on August 31, 2026. We chose the Balanced v3 strategy and specified-content mode, then confirmed that the scope contained one paragraph and 133 English words before starting.

The 32-second duration and 14-credit charge are records of this job, not promises about another file. Processing time and cost can change with the selected text and product state.

The output hash differs from the input hash, as it should: the selected paragraph changed. A whole-file hash can prove that two files differ, but it cannot say whether the difference is limited to the intended paragraph. That required a part-by-part comparison.

A DOCX is a ZIP package containing XML parts, relationships, media, styles, and other resources. The input and output each contained 20 parts, and the part-name sets matched exactly.

All seven sentinel groups also kept their input counts. The percentage remained `37.5%`, the measurement remained `12.40 mg`, and no protected anchor gained or lost an occurrence.

We then hashed every internal part. Eighteen part hashes were identical, and two differed.

In `word/document.xml`, where the body paragraph lives, the formatted diff contained one changed `w:t` text node: the selected paragraph. No other formatted node in that part changed.

The second raw hash difference was `[Content_Types].xml`. It remained 2,125 bytes and kept the same `Default` and `Override` entries. The output moved the existing `/word/comments.xml` override from the end of the list into the other Word overrides. No content type was added, removed, or changed. This ordering difference is easy to miss if a comparison reports only the part names or parsed entry set.

That is stronger than saying the file still had 20 parts. A part can retain its filename while its contents change. It is also stronger than a visual spot check, because a comment relationship or content control can be present in the file without looking like ordinary body text.

It is still not the same as exercising each object in Word. Equal counts and matching XML structures show what remained in the package. They do not show that a reviewer clicked the comment in the Review pane, accepted the old insertion, rejected the old deletion, or refreshed the REF field in desktop Word.

Both versions rendered to two pages. The image comparison identified page 2 as the only changed page.

• Page 1, which contained the tracked changes, comment anchor, content control, bookmark, REF field, and table, was visually unchanged.
• Page 2 changed where the selected paragraph appeared.
• The new sentence lengths caused normal line reflow on page 2.
• The rendered output showed no clipped text, overlapping text, missing table, or broken table geometry.

The extracted-text diff reached the same boundary: it showed the selected paragraph changing while the scope note after it stayed in place.

Rendering answers a different question from the package audit. The package audit checks structure. Rendering checks the pages a reader would see. A file can pass one and fail the other, so neither result should stand in for both.

An unchanged count is useful only if the counter can detect loss. We tested that with two deliberately damaged copies.

In the first copy, we stripped the comment structures. The same auditor then reported zero comment bodies, zero range anchors, zero comment references, zero comment relationships, and zero comment content-type entries.

In the second copy, we accepted the tracked changes. The auditor reported zero tracked insertions and zero tracked deletions.

Those positive controls show that the audit path can catch the two losses we created. They do not certify the auditor against every possible DOCX fault. A broken drawing relationship, malformed equation, or damaged macro would need its own check and its own known-bad control.

Use a disposable copy. Your test should contain the objects that would be expensive to repair in the real document, not a generic paragraph with no Word structure.

1. Add one identifiable example of each object you depend on. That might be a tracked insertion, tracked deletion, comment, citation-manager control, bookmark, cross-reference, footnote, table, equation, or caption.
2. Put a unique anchor next to each object, such as `CHECK-COMMENT-01` or a number with its unit. Record the expected count.
3. Keep those controls outside one ordinary paragraph. Select only that paragraph for rewriting and confirm the final scope before the run.
4. Save the untouched input. Record its byte size and SHA-256. A simple `shasum -a 256 your-file.docx` command works on macOS.
5. After download, record the same values for the output. Compare the DOCX part lists, then parse the relevant XML parts for object counts. Do not grep the compressed DOCX bytes and call that an audit.
6. Render both files with the same renderer and compare page count, text, and images. Natural line reflow is different from clipping, overlap, or a missing object.
7. Open the output in the desktop Word version you will use for delivery. Inspect All Markup and the Comments pane, exercise one content control, refresh one field, save under a new name, close, and reopen it.
8. Make one deliberately damaged copy and confirm that your check reports the loss. Without that control, a clean zero may mean the measurement never saw the object.

Do not combine these checks into a percentage. If the comment fails while nine other rows pass, the comment is still a failed requirement. The acceptance decision belongs to the document object you need.

This run does not support a universal preservation claim. It did not test:

• comments or tracked changes inside rewritten text;
• live Zotero, EndNote, or Mendeley libraries;
• footnotes, equations, macros, embedded files, text boxes, or floating images;
• section-specific headers and footers;
• another HumanPen strategy or a full-document rewrite;
• another Word version or operating system;
• the factual quality of the rewritten paragraph; or
• any AI detector result.

The manual Microsoft Word reopen remains the largest open check. The OOXML and render results are evidence, but they do not let us claim that Word opened the file without a repair warning or that every preserved object remained interactive.

The right conclusion is small and useful: in this one specified-content HumanPen run, the selected paragraph changed, the instrumented objects outside it kept their measured package structures, and the rendered document stayed intact. Your own DOCX still needs its own acceptance test.

Does HumanPen preserve Track Changes? In this single run, one pre-existing tracked insertion and one pre-existing tracked deletion remained present in the returned DOCX package. We did not manually accept or reject them in Microsoft Word, so their desktop-Word behavior remains unverified.

Does HumanPen preserve Word comments? In this file, the comment body, start and end anchors, in-document reference, package relationship, and content-type entry each remained present. The comment was not manually opened in Word's Comments pane after download.

Does a matching part count prove that a DOCX is safe? No. A part can keep the same name while its contents change. Compare part hashes, inspect the changed XML, check object-level counts, render the pages, and exercise the objects in Word.

Should I expect the same result for my thesis or report? No single fixture can cover every Word object. Build a small test file that mirrors the structures your real document uses, run the same scope and settings you plan to use, and keep an untouched original.