Why Google Docs exports look different in a forensics scan

A large fraction of student submissions in 2026 are Google Docs that have been File → Download → Microsoft Word (.docx)'d at submission time. The resulting docx has a different forensic signature from a docx authored in Word directly. Instructors who don't know what to look for sometimes misread the differences as evidence of tampering. This page covers what to expect from a Google Docs export and how to distinguish it from suspicious file shapes.

What changes when you export from Google Docs

When Google Docs writes a .docx, it does so through its own renderer. The output is a valid Microsoft Word file, but the underlying XML is structured the way Google's exporter writes XML, not the way Word writes XML. Specifically:

Metadata fields

• app.xml carries Application: Microsoft Office Word (Google Docs pretends to be Word so the file opens correctly) but Company, AppVersion, and other Word-only fields are typically empty or have placeholder values.
• core.xml carries creator: Anonymous if the user wasn't signed in to the export, or the Google account's display name if they were.
• TotalTime is always 0 for a fresh export. Google Docs doesn't track desktop-Word-style editing time.
• revision: 1. Always.
• lastModifiedBy is whoever exported the file at export time — usually the student's Google account name.

Edit history

• No revisions.xml. Google Docs has its own revision-history system; the export doesn't carry it. So the paste-detection signal can't fire — there's nothing to read.
• No tracked changes (unless the student turned on "Suggesting mode" in Docs, which sometimes survives the export as <w:ins> elements).
• No autosave timeline. The docx is a single-snapshot export.

Settings and styles

• settings.xml has different defaults than a Word-authored file (different page setup, different proof state).
• styles.xml uses Google Docs' default style names ("Heading 1" with Google's exact font choices, etc.).
• Embedded images are stored differently; image paths use Google Docs' conventions.

What this means for forensics reading

A Google Docs export looks, to an unsophisticated reader, like a stripped or tampered docx. Many of the fields a normal-Word forensics workflow checks are empty or zeroed. The temptation is to read this as suspicious. Don't. The pattern is just "this came from Docs."

Specifically, the following pattern is consistent with a normal Google Docs export:

• Application: Microsoft Office Word
• TotalTime: 0
• revision: 1
• Company: empty
• No revisions.xml
• No tracked changes
• Recent lastPrinted is empty
• creator may or may not match lastModifiedBy

If a submission looks like that, the most likely explanation is "Google Docs export." Ask the student.

How to confirm a Google Docs export

A few file-structural tells:

• The dc:creator field — Google Docs often writes it as the Google account display name on first creation. Some students don't realize their Docs identity is their full name and email-prefix-based display.
• The XML namespace declarations in document.xml — Google's exporter uses a slightly different set than Word does. Forensics tools (including Autotend Forensics) can fingerprint this.
• Style names — Google Docs writes "Normal" with specific default values that differ from Word's "Normal".
• <w:rsid> patterns — Word generates random revision-save IDs that change with each edit session; Google Docs writes them in a different, recognizable pattern.

The forensics scoring engine recognizes Google Docs exports as a known-clean origin pattern. The structural signals deep-dive describes the detector that fingerprints this case.

When a Google-Docs-export pattern IS suspicious

Less often, but worth knowing:

• The student claims to have written in Word. If the file structure says Google Docs but the student insists they used desktop Word, the inconsistency is worth a conversation. Most students don't realize the export is so distinctive.
• Multiple submissions across a class show Google-Docs-export patterns from the same Anonymous creator. That's consistent with a shared Doc being downloaded by multiple students.
• The creator field is the name of someone other than the student. Could be a tutor, a paper mill, or a friend who shared a Doc. Worth asking.

In none of these cases is the file-structure alone proof of anything; they're conversation prompts.

The deeper point

Document forensics in 2026 has to handle the fact that most student writing doesn't happen in Word anymore. Google Docs, Microsoft 365 Online, Apple Pages, and a long tail of mobile apps each leave different forensic signatures. The right baseline for "what does authentic student work look like?" is the per-class distribution of submission patterns, not Word-desktop-from-1998.

Autotend Forensics' per-paper rolling baseline handles this — it compares each submission against the other submissions to the same assignment, not against a fixed "what a Word file should look like" template. A class where 80% of submissions are Google Docs exports establishes that as the norm; outliers in either direction get flagged.

What to do if you see a Google-Docs-export pattern

1. Don't escalate on the pattern alone. It's normal.
2. If the assignment expected tracked changes or a specific Word-side workflow, ask the student about their drafting process. A simple "did you draft in Docs?" usually resolves it.
3. Treat the absence of edit-history signals as a known limitation. You won't have paste-detection or tracked-changes signals on a Google Docs export. Rely on metadata, structural, and the rolling baseline.

For the full structural-signals methodology, including how the scoring engine fingerprints different document origins, see the structural signals page.