Track Changes
Track Changes is a feature in word processing programs that visibly marks every change made to a document instead of simply applying it. Anyone reading the text later can see exactly who deleted, inserted, or commented on what, and can accept or reject each change individually.
When two people work on the same text one after another, a problem arises. The second person overwrites the first person’s sentences, and afterward no one can tell what was originally there. Track Changes solves this: the program stores every edit as a suggestion, not as a finished fact. Deleted words remain visible, struck through, and new words appear highlighted in color. In the end, one person decides which suggestions make it into the final text. The English name of the feature is usually “Track Changes.”
Who bears responsibility for the final text
In editorial offices, law firms, and government agencies, a document often passes through five or more hands. Without markings, by the third round it would be unclear which wording was intentional and which was a mistake. Track Changes makes this chain fully visible without gaps. Each person is assigned their own color, and every change gets a timestamp.
In contracts, this is not just convenient but legally important. If one party replaces the word “may” with “must” in a draft contract, that changes the legal situation significantly. Such interventions must be recognizable to the other side. A draft that comes back without visible markings is considered unprofessional in many industries.
Since AI tools started rewriting texts, the feature has taken on additional significance. A language model — that is, a program that formulates text — often delivers a completely new version. Without markings, one would have to compare both versions word for word. That’s why more and more providers are building their AI suggestions directly in as tracked changes.
What the program stores in the background
Technically, the file stores not only the visible text but also a list of interventions. Each intervention includes four pieces of information: the location in the text, the type of change, the name of the editor, and the timestamp. A deleted word doesn’t actually disappear from the file. It merely gets a marker that tells the program: don’t display this as normal text anymore.
When a change is accepted, the marker is resolved and the intervention is carried out permanently. When it is rejected, the opposite happens: the old state returns. As long as this hasn’t happened, both versions exist simultaneously in the same file.
This creates a risk that many underestimate. Anyone who sends out a document with still-open changes unintentionally reveals their internal discussion. There have already been cases where journalists turned deleted passages from a press release into a story of their own. Before sending a document, one should therefore accept or reject all changes and delete comments.
From Word to the pull request
The feature is best known in Microsoft Word, where it sits under the “Review” tab. Google Docs offers the same thing under the name “Suggesting mode,” LibreOffice under “Record Changes.” Anyone who has a term paper corrected during their studies will almost always get it back in this form.
In software development, there is a related principle with a different name. There, changes to program code are proposed via what is called a pull request. Here too, one sees line by line what was added and what was removed, and someone else must approve it. The underlying idea is the same: changes are, at first, only suggestions.
A common misconception is confusing Track Changes with version history. Version history stores entire intermediate states of a document that one can jump back to. Track Changes works more finely and shows individual interventions within a single state. In practice, both are used side by side.