Can students fake a writing history?

The answer

Yes. If the writing history you are relying on is a Google Docs or Microsoft Word version history, a student can fabricate it with tools built for the purpose. Phrasly sells a Human Auto Typer; Undetectable.ai, TypeX and naturaltypist.com offer the same thing. Each takes a block of text, usually generated, and types it into the document one character at a time so that the version history fills in as if a person had written it. The tools are named openly in faculty forums, including an r/Professors thread from May 2026.

Source: phrasly.ai/human-auto-typer; r/Professors, May 2026, naming naturaltypist.com; checked 2026-09-08.

That does not make a document history useless. It makes it one signal among several, and a signal that has to be read knowing what it can be made to show.

Why the question comes up

Instructors who have stopped trusting AI detectors, for good reason, have turned to revision history as the alternative. Draftback replays a Google Doc’s history keystroke by keystroke and has about 400,000 Chrome Web Store users; it went paid in early 2025 at $40 per year for teachers. Revision History, from TabWrite, claims more than 200,000 teachers and offers a free tier of 150 documents a month. Both are good at what they do. The students know this too, which is why a market in auto-typers exists: if a teacher is going to watch the history, the history has to look right.

Source: Chrome Web Store listing and draftback.com; revisionhistory.com; checked 2026-09-08.

Revision History’s own copy disclaims being proof of authorship and notes that a student can turn Google history off. Neither Docs nor Word records keystrokes; both record document states, and neither distinguishes typed text from pasted text. Word’s Track Changes can be disabled by the author. A history built on those foundations was never designed to resist someone who wants it to lie.

Source: revisionhistory.com; learn.microsoft.com Q&A on Word version history; checked 2026-09-08.

What a fabricated history looks like

A real drafting session is uneven. A person types in bursts, stops to think, deletes half a sentence, goes back two paragraphs to fix a claim, pastes a quotation and then trims it, and rearranges the order of the body. An auto-typed session is the opposite of all that:

• Uniform rhythm. Characters arrive at a steady rate from the first word to the last. Timing that has been varied on purpose still has no relationship to how hard each sentence was.
• No deletions. The text is already final, so nothing is taken back. If a typo is corrected, it is the only editing in the document.
• No pauses where thinking happens. A writer stalls before a hard paragraph. An auto-typer does not know which paragraph is hard.
• No reordering. The essay is typed top to bottom, introduction first, conclusion last, in one pass. Almost nobody writes that way.
• One sitting. A 1,500-word essay appears in a single session, often late at night, with no earlier document states.

Any one of these describes some honest students. Together, in a document that arrived complete, they describe a transcription, and that is the point at which a document history stops being evidence of writing and becomes a reason to ask.

What a keystroke-level record does differently

A record that captures the session rather than the document has three things a version history does not, and the third is the one that matters for fabrication.

First, it records keystrokes, revisions, pauses and pastes, not states. Pasted text is marked as pasted and stays marked, so a quotation and a generated paragraph are distinguishable at a glance. Second, the timestamps are set on the server, not by the student’s machine, so the timing of the session cannot be edited after the fact. Third, EssayGuard takes periodic snapshots of the document and cross-checks them against the event stream. Real typing produces a stream and a set of snapshots that agree. An auto-typer driving a browser editor produces a stream that does not line up with what the document actually contained at each snapshot, and EssayGuard reads that inconsistency as unrecorded rather than as writing.

An unrecorded session is not a verdict. It means the record cannot vouch for how the text arrived, and it hands the instructor a specific, checkable reason to talk to the student. That is a different situation from a fabricated Docs history that looks fine, which hands the instructor nothing.

What to do next

1. If your class writes in Google Docs, keep reading histories, and read them as one signal. A single-sitting, no-deletion, top-to-bottom history is a reason to ask a question, not a finding.
2. Check the sources in the paper. A fabricated citation is concrete evidence that no auto-typer can hide.
3. Talk to the student about the argument before you mention the history. A writer can explain their choices; a transcriber usually cannot.
4. For the next assignment, have the class write in a recorded editor so the record exists from the first keystroke. The syllabus language page covers how to say so.
5. Hold to the rule that no penalty rests on a single signal, whatever the signal is.

What not to do

• Do not treat a clean-looking Docs history as proof that the student wrote the paper. It can be produced to order.
• Do not treat a suspicious one as proof they did not. Some students draft on paper and type up a finished version in one sitting.
• Do not run the paper through an AI detector to break the tie. Detector error rates are documented on the false-positive page, and a percentage does not resolve a question about process.
• Do not accuse in writing before the conversation. The first message should be a question about the work.

What still cannot be proven

No tool, including EssayGuard, can show whether the ideas in a paper were the student’s. A student who reads generated text from a phone and retypes it slowly, pausing and correcting, produces a record that looks like drafting, because it is a kind of drafting. A student whose friend dictated the outline produces a genuine record of typing someone else’s thinking. A keystroke-level record shows how text entered the editor, typed or pasted, in what order, with what pauses and rewrites. It rules out the cheapest shortcut and makes the rest visible enough to talk about. The record is evidence for a conversation, and the conversation is still where the finding is made.