Spotting the exact difference between two similar blocks of text by eye is slow and error-prone — a single changed word in a long paragraph is easy to miss. This tool compares two texts and highlights precisely what was added, removed or changed.
A problem formalized well before modern version control existed
The algorithmic problem of finding the minimal set of differences between two sequences — known as the "longest common subsequence" problem — was studied in computer science through the 1970s, with foundational work by researchers including Eugene Myers, whose 1986 diff algorithm remains, in refined form, at the core of the Unix diff utility and, decades later, Git's own diff engine. This shared algorithmic lineage is why a "diff" in a code review tool and the line-by-line comparison in a word processor's "track changes" feature are conceptually solving the exact same underlying problem, just applied to different kinds of content.
How the comparison works
The tool analyzes both texts to identify the longest sequences of matching, unchanged content, then highlights everything else as either an insertion (present in the second text but not the first), a deletion (present in the first but not the second), or occasionally a modification (represented as a paired deletion and insertion) — aiming to find the smallest, most intuitive set of changes that explains the difference between the two versions, rather than a technically correct but confusingly scattered set of matches.
Where comparing text like this is genuinely useful
- Reviewing edits to a document or contract — quickly identifying exactly what changed between two versions of a legal document, policy, or piece of written content without manually re-reading both in full.
- Comparing configuration files or code snippets — spotting the precise difference between two versions of a config file or short code block when a full version-control diff isn't readily available.
- Verifying translated or paraphrased content — checking how closely a revised piece of writing matches its original, useful for editorial review or plagiarism-adjacent content checks.
- Auditing changes to structured text data — comparing two exports or snapshots of the same data (like two versions of a CSV or log file) to identify exactly what changed between them.
Frequently asked questions
Does the diff algorithm always find the "correct" set of changes? It finds the minimal, most intuitive explanation of the differences according to its algorithm, but text with significant reordering or a large number of scattered small changes can occasionally produce a diff that's technically accurate but doesn't match how a human would naturally describe the edit.
What's the difference between a word-level and character-level diff? A character-level diff highlights differences down to the individual letter (useful for catching a single typo fix), while a word-level or line-level diff groups changes at a coarser granularity, generally producing more readable results for substantial edits to prose or code.
Is this the same technology Git uses for code diffs? Conceptually yes — Git's diff engine is built on the same longest-common-subsequence family of algorithms, applied specifically to lines of code rather than general prose, though the underlying "find the minimal set of changes" problem is fundamentally the same.
Further reading
Wikipedia — Diff — History of the Unix diff utility and the algorithms underlying modern text comparison tools.