The feature that records and displays edits made to a document is tracked changes, usually surfaced as Track Changes in Microsoft Word and Google Docs, or as change tracking plus version history in LibreOffice and Pages. It captures each insertion, deletion, formatting tweak, and comment as an attributed revision, then renders those revisions inline, in a markup pane, or as a recoverable past version. The record persists until someone accepts or rejects the change or clears the version log.
The recording mechanism behind tracked changes
Track Changes works by intercepting edits at the document-model layer rather than rewriting text in place. When you type with tracking enabled, the application wraps the new characters in a revision object that stores four things: the author identity, a timestamp, the edit type, and the range it affects. The original text stays in the file alongside the replacement, which is why a deleted word still appears struck through rather than vanishing.
Display is a separate rendering pass. The same stored revision can be shown as inline markup, as balloons in a margin pane, or as clean final text, depending on the view setting. That separation matters: turning off markup display does not delete the record. A reviewer who switches to "No Markup" sees a tidy page while the edits remain embedded and will reappear when the view changes back.
Version history is the second, coarser layer. Where tracked changes are object-level and attributed, version history is snapshot-level. Google Docs autosaves continuously and keeps named and automatic versions, so you can restore a state from minutes or days earlier. Microsoft Word's AutoSave to OneDrive keeps a version list with timestamps, while the older AutoRecover is a crash-recovery buffer, not a revision log. The two systems complement each other: tracking shows what changed line by line, history shows when the whole file changed.
Plain-language version: tracking records each edit as a labeled object, and the display merely chooses how to draw those objects.
Quantified context: storage, retention, and scale
Concrete limits shape how much edit history you actually get. Microsoft Word stores up to 32 author names in the user-information settings, which caps how many distinct reviewers a single file cleanly attributes before names recycle (Microsoft Support). Google Docs version history lets you name versions and browse a timeline, but automatic versions can be thinned over time as older intermediate saves are consolidated rather than kept indefinitely (Google Workspace documentation).
File size grows with revision count. Each tracked change carries metadata, so a heavily reviewed 50-page contract with hundreds of insertions and deletions can inflate noticeably compared with a clean copy. Accepting all changes strips the revision objects and typically shrinks the file. Retention also depends on storage: Word's version list lives with the cloud copy under OneDrive or SharePoint, so deleting the cloud file deletes its history, while local-only files keep no server-side version list at all.
Defaults differ by platform. Word enables Track Changes per document and remembers the setting for that file, so a document can arrive with tracking already on. Google Docs uses suggestion mode, which you toggle per session and which does not silently persist the way a per-file Word setting can.
Edge cases that break the record
Several situations quietly defeat edit recording. Files converted between formats are the most common culprit. Round-tripping a .docx through .odt or .rtf can flatten or drop revision objects, and pasting tracked text into a plain-text field preserves the words but not the authorship.
Compare-and-merge is the recovery path most users miss. If tracking was off and two people edited copies independently, Word's Compare feature or Google Docs' comparison of two versions can generate a difference report after the fact, reconstructing what changed even without live tracking. It is not perfect for formatting-only changes, but it recovers text-level edits.
Other failure points:
Editing in a viewer or mobile app that supports display but not recording, so changes vanish without a revision trail. Accepting all changes before sharing, which permanently deletes the record and cannot be undone by toggling a view. Sharing a file by email attachment instead of a link, creating divergent copies whose histories never merge. Turning off AutoSave or working offline in Word, which suspends cloud version capture until reconnection. Pasting from a tracked document into another tracked document, which can carry over the source author's identity on those characters.
Counterintuitive caveat: displayed markup is not proof the edit is recoverable. If an author accepts changes and saves, the underlying original text is gone from that file, even though it looked trackable moments before.
Timeline of a tracked edit
| Stage | What happens | What the record shows |
|---|---|---|
| Edit made with tracking on | Revision object created and attributed | Inline insertion or strikethrough with author |
| Autosave fires | Version snapshot captured in cloud storage | Timestamped version in history list |
| Reviewer displays markup | Rendering pass draws revisions | Balloons, strikethrough, or margin notes |
| Comment added | Separate annotation object attached | Threaded note tied to a range |
| Change accepted or rejected | Revision object resolved and removed | Clean text; record deleted from file |
| File shared by link | Live history syncs to collaborators | All prior versions visible to editors |
| Export to PDF | Revisions flattened or markup printed | Static image, no editable record |
The table shows why timing matters: the moment a change is accepted, that row of history is unrecoverable within the file, only in an earlier saved version if one exists.
Misconceptions about edit recording
The largest misconception is that Track Changes and version history are the same thing. They operate at different granularities. Tracking is per-edit and shows intent; history is per-save and shows state. You can have one without the other, and neither guarantees the other.
A second myth is that undoing an accepted change restores the original. Undo works within the session's edit stack, but once a change is accepted and the document saved or reopened, undo no longer reaches it. The original survives only if a prior version snapshot exists.
People also assume tracking is automatic and always on. It is not. Word's tracking is a per-document setting that can be off by default, and Google Docs requires you to switch to suggestion mode deliberately. A document can be edited with no record at all if neither is engaged, which is precisely why compare-and-merge exists.
Finally, hiding markup is often mistaken for removing it. Switching the view to "No Markup" or "Original" changes only what is drawn on screen. The revisions are still in the file and will show again under a different view or on another reviewer's machine.
Practical actions to guarantee a record
Set tracking before you start, not after. In Word, open Review, turn on Track Changes, and confirm the author name under File options so attributions are accurate. In Google Docs, switch to suggestion mode before typing and name key versions at milestones.
Share by live link rather than attachment whenever collaboration is expected. Link sharing keeps one file and one history; attachments fork the record. For contracts and formal review, agree in advance that reviewers will use suggestion mode and leave changes unresolved until a final pass.
When tracking was missed, run a comparison as soon as you notice. Word's Compare or Google Docs' version comparison can reconstruct text-level differences between two files, and restoring an earlier version from history recovers a prior state. Adopt thresholds: if more than about 25 percent of a paragraph changed with tracking off, compare rather than trust memory.
Before accepting anything, export or name a version you can return to. Treat "Accept All Changes" as a destructive action requiring a saved prior version, because it permanently deletes the revision objects and the original wording with them.
Limitations and what tracking cannot do
Tracking records edits to text and formatting, not the reasoning behind them, and it cannot attribute edits made while tracking was off. Formatting-only revisions can be harder to spot in some views and may not round-trip cleanly between applications. Cross-format conversion, plain-text channels, and offline work all create gaps that no setting fully closes.
There is also no universal retention guarantee. Cloud version thinning, storage limits, and organizational policies can prune history, and a deleted file takes its versions with it. Tracking proves what changed in a file, but it is not an audit-grade record unless the platform's version retention and access controls are configured to preserve it.
This article is general educational information about document software features, not legal or compliance advice. Edit records used for contracts, regulated records, or evidentiary purposes may require platform-specific retention settings reviewed by a qualified professional.