Can Google Docs version history show whether a student pasted an essay?

Sometimes. Version history saves named and automatic snapshots of the document, so if a large block of finished text appears between one snapshot and the next with nothing in between, that is visible and worth asking about. What it cannot tell you is whether that block was pasted, typed quickly, or written in a stretch that Docs happened to compress into one version. Docs records the state of the document at intervals, not the individual edits that produced it, and it never records a paste as a paste.

How do I check version history in Google Docs?

Open the document and choose File, then Version history, then See version history, or press Ctrl+Alt+Shift+H. The right-hand panel lists timestamped versions; expanding a day shows the finer-grained versions inside it. Clicking one shows that state of the document with the edits since the previous version highlighted, coloured by editor. To do this you need edit access to the file, so it works for documents shared with you or created from an assignment template, and not for a file a student only exported as a PDF.

What does a keystroke replay record that version history does not?

The individual edits and their times. A replay logs each insert with its position and text, each delete, each cursor jump, each window focus change, and each blocked paste attempt with its size in characters, all with millisecond timestamps. That gives typing cadence, pause lengths, the size of every insertion, and the count of paste attempts, none of which survive being flattened into a snapshot. Version history is a series of photographs of the document; a replay is the recording of it being written.

Google Docs version history vs a process replay

Version history is the most-used piece of process evidence in schools, it is free, and it is already on every student's account. It is also a series of snapshots, and there are specific things that fall between the snapshots. This is what each one actually records.

How to look at version history first

Before anything else: if the work is in a Doc you can open, go and look. File → Version history → See version history, or Ctrl+Alt+Shift+H. The panel on the right lists timestamped versions, grouped by day; expanding a group shows the finer versions inside it. Click one and you see the document as it stood, with changes since the previous version highlighted and coloured per editor. You need edit access, so this works for a Doc shared with you or made from an assignment template in Classroom, and not for a PDF a student exported and handed in.

What you are looking for is shape. A document written over four sittings, with sentences appearing and being reworked, looks like a document that was written. A document with two versions — an empty one at 10:02 and a complete 900-word essay at 10:04 — looks like something else, and is worth a calm question.

What version history genuinely shows

Elapsed shape over days. Whether the essay grew across sessions or appeared in one. This is the single most useful thing about it, and no keystroke tool that starts at the assignment beats it for a piece written over two weeks.
Who edited. Named collaborators, colour-coded, which settles a surprising number of "we worked together" questions.
Rough growth. Comparing consecutive versions shows what appeared between them.
It exists already. No new tool, no new account, no new privacy review. That is not a small advantage in a school.

The four things it misses

None of these are Google doing something wrong. Version history was built so you could restore yesterday's draft, not so a teacher could adjudicate authorship. It does that job well. The gaps are a consequence of the design.

A paste is never recorded as a paste. Docs stores the resulting text, not the action that produced it. Pasted text and typed text look identical in a snapshot, and there is no count of paste attempts anywhere in the interface.
Timing inside a version is gone. Versions are checkpointed at intervals Google chooses. Everything that happened between two checkpoints is flattened into a single diff, so a paragraph that took eleven minutes with three rewrites and a paragraph that arrived in one second can be the same entry in the panel.
Bulk inserts are ambiguous. A 900-word jump between versions is a genuine flag — and it is also what you get when a student writes offline in another app, or in the Docs mobile app on a patchy connection, or when a long stretch of steady writing lands in one checkpoint. You can see that a lot of text appeared; you cannot see how.
Nothing outside the document. A tab switch, a second window, a phone next to the keyboard — none of it is in scope, and it never will be.

There is a fifth practical problem: the record belongs to the student's file. It can be deleted, the file can be copied into a fresh document that starts with a clean history, and ownership can be transferred. A student who wants to sanitise a history can, and it takes about a minute. Again, not a flaw in Docs — it is a document tool, and people are allowed to copy documents.

What a keystroke-level replay records instead

A process replay logs the edits themselves rather than the states between them. Each insert with its position and its text, each delete, each cursor jump of more than a character, each window blur and focus, each blocked paste, drop or drag attempt with its size, all carrying a millisecond timestamp. The document is then rebuilt from that log, which means you can play it back and watch the essay being written, scrub the timeline, and jump to a marked moment.

Because the individual edits survive, so do the things that were flattened out of a snapshot: typing cadence, the length of every pause, the size of each insertion, how many characters were deleted during revision, how often the window lost focus. The single most useful figure is the split between typed and inserted characters, because ordinary typing arrives one to three characters at a time and a block that arrives at once did not come from fingers.

Which to use, honestly

Long take-home work, drafted over days: version history, easily. It is already there, it spans the whole period, and it costs nothing. A replay tool only sees what happened inside its own editor.
A single sitting where authorship might be questioned: a replay. Timing, insert sizes and paste attempts are exactly the evidence a one-period draft turns on, and those are what the snapshots lose.
A dispute already underway: both, plus a conversation. Look at the history you have, then set a short recorded piece so there is one artefact where the process is unambiguous.
Classes without Google accounts: version history is not available to you at all, which decides it.

The two are not really competitors. One is a document tool that happens to keep useful history; the other is a recording of a writing session. Most teachers who ask about this end up using version history for the projects and a recorded draft for the high-stakes pieces.

Where WrittenLive fits

WrittenLive records the writing process and replays it — that is all it does. Type an assignment title, get a student link and a private dashboard link, no accounts on either side. Students open the link, type a name and write; paste, drop and drag-in are blocked and counted; every edit is timestamped. Afterwards you get the scrubbable replay, a class table, a CSV, and a one-page printable authorship report per student. It runs in the browser on a Chromebook or a phone, and it is free for one class this school year.

It makes no AI-detection judgment and contains no model scoring anyone's prose. Every number on the report is something the editor observed. A flag means "this pattern is worth asking about", never "this student cheated" — see what to do when a detector flags an essay for why that distinction matters so much in practice.

The limits, said plainly

A replay only covers writing done in its own editor, so it is no help for work already handed in — version history is your only lead there. It cannot see other screens, other devices, or who is at the keyboard, so a student retyping from a phone produces a record that says "typed", because they did type it. Long idle gaps and fast bursts are patterns, not intent. And running a session in a second tool means the writing happens outside Docs, which is a real cost if your whole workflow is in Classroom — for a one-period draft it is usually a link in the stream, and for a two-week project it is probably not worth it.

Made by a developer after teachers asked for it. One person, hosted on Cloudflare, not a startup, and not affiliated with Google in any way. Free for one class this school year, no card field anywhere in the product.

See a real replay

Or open the public demo dashboard first — one clean session, one with paste attempts and a large insertion.