How a text diff works: line, word and character diffs, the longest common subsequence, reading added and removed lines, and the whitespace traps to avoid.
By Udit Agarwal · Updated October 17, 2026
A text diff is the list of changes that turns one version of a text into another: what was removed, what was added and what stayed the same. Diff tools find it by matching the longest sequence of content the two versions share in the same order, then marking everything else as a removal or an addition. The result is the red-and-green view used in code review, document comparison and version control.
A diff sorts two versions into three groups. Unchanged content appears in both, in the same order. Removed content is only in the original and is usually shown in red with a minus sign. Added content is only in the new version and is shown in green with a plus sign. There is no separate "changed" group: an edited line is reported as the old line removed and the new line added.
apple
- banana
+ blueberry
cherry
Here the first and last lines match, banana was taken out and blueberry put in. Read the minus lines as "what used to be here" and the plus lines as "what is here now".
What a diff compares changes what it shows. Take one line edited from "The meeting is on Tuesday at 3 pm." to "The meeting is on Thursday at 3 pm.":
| Diff type | Compares | Reports for this edit | Best for |
|---|---|---|---|
| Line | Whole lines | The old line removed and the new line added | Code, config files, logs, lists |
| Word | Words | "Tuesday" replaced by "Thursday" | Prose, contracts, articles |
| Character | Single characters | "h" and "r" added, "e" removed | Typos, IDs, numbers, short strings |
Line diffs are the standard for source code, which is written one statement per line, and they are what version control systems such as git show by default. Their weakness is prose: a paragraph is usually one long line, so one changed comma marks the whole paragraph as removed and re-added. Word diffs highlight only the words that changed, and git diff --word-diff produces one. Character diffs pick out a single wrong digit in a long number but turn a rewritten sentence into a scatter of letters.
Most diff tools are built on the longest common subsequence (LCS): the longest list of items, lines in a line diff, that appears in both versions in the same order, though not necessarily side by side. Everything in the LCS is unchanged. Everything else in the original is a removal, and everything else in the new version is an addition.
Compare the lines A B C D E with A C D F E. The longest sequence they share in order is A C D E, four lines. That leaves B, found only in the original, as a removal and F, found only in the new version, as an addition. Two edits is the fewest that can turn one list into the other, which is what the LCS guarantees.
The classic way to compute it fills in a table with one row per line of the original and one column per line of the new version, so the work grows with the product of the two lengths. Two 2,000-line texts need a table of about four million cells. Unix diff, written in the 1970s, was built on the LCS idea, using the Hunt–McIlroy algorithm. Eugene Myers' 1986 algorithm, the default in git and the basis of GNU diff, reaches the same kind of answer much faster when the versions are mostly alike.
Start with the totals. A count such as +12 −3 gives the size of the change before you read any of it. Then read each block of red and green as a pair: the red lines are the old version of that passage and the green lines the new one. Unchanged lines around them are context that shows where the change sits.
Command-line tools such as git and diff -u print the unified format, which adds a header to each block of changes:
--- a/notes.txt
+++ b/notes.txt
@@ -1,3 +1,3 @@
apple
-banana
+blueberry
cherry
The @@ -1,3 +1,3 @@ line means the block starts at line 1 and covers 3 lines of the old file and 3 of the new one. Lines that start with a space are unchanged, - lines were removed and + lines were added. Most patch files use the same format.
A diff compares text exactly, so differences you cannot see still count. A space at the end of a line, a tab where the other version has spaces, a non-breaking space pasted from a web page, a zero-width space, curly quotes against straight ones or a capital letter all make two lines unequal, even when they look identical on screen.
Line endings are the best-known trap. Windows text files end each line with a carriage return and a line feed (CRLF), while macOS and Linux use a line feed alone (LF). Tools that compare files directly, such as git, can mark every line as changed when only the line endings differ, sometimes with a stray ^M at the end of each line. Text pasted into a browser's text box avoids this, because browsers turn every line break in a text box into a single line feed.
The end of the text matters too. If one version ends with a line break and the other does not, the diff shows an extra blank line added or removed at the bottom; git reports the same thing as "No newline at end of file".
GNU diff has options to ignore these differences: -w ignores white space, -b ignores changes in the amount of white space, -i ignores case and --strip-trailing-cr drops Windows carriage returns, and git diff -w works the same way. In a browser, clean both versions identically before comparing. The AI Text Cleaner removes zero-width and non-breaking spaces and can straighten quotes and collapse runs of spaces, and Find and Replace handles the rest, such as swapping tabs for spaces with its regex mode. To compare two lists where the order does not matter, sort both first with Sort Text Lines.
Code suits a line diff, with one catch: formatting. If one version went through a code formatter and the other did not, indentation and line breaks change everywhere and the real edit is buried, so format both versions the same way first. For JSON, skip the text comparison: JSON Diff parses both documents and reports each added, removed or changed value with its path, and it ignores the order of keys, which a text diff cannot do.
Prose needs more care. Hard-wrapped text, such as an email broken at a fixed width, reflows when a word is added, so every later line in the paragraph changes, while a paragraph typed as one long line is marked whole for a single edit. Unwrap both versions with Remove Line Breaks in its Keep paragraphs mode, put each sentence on its own line, and a line diff behaves much like a sentence diff. For a word-by-word view, Prompt Diff, built for comparing versions of an AI prompt, compares two texts by word and counts the words added and removed.
The Text Diff compares two pasted texts line by line. Paste the old version into Original and the new one into Changed. The diff appears underneath and updates as you type, as one combined list: unchanged lines in grey, removed lines in red with a minus sign and added lines in green with a plus sign. A changed block shows its old lines first and its new lines after them, and a count above the list gives the number of lines added and removed.
It does one kind of comparison, using the longest-common-subsequence method described above, and it has no settings:
Both texts are compared in your browser and nothing is uploaded. For documents, Compare PDFs extracts the selectable text from two PDF files and runs the same line-by-line comparison, pausing above 5,000 lines.
How do I compare two texts for differences? Paste the original into one box of a diff tool and the new version into the other. The tool lines up what the two share and marks the rest: lines only in the original as removed and lines only in the new version as added. The ArrayKit Text Diff does this as you type.
What do the plus and minus signs in a diff mean? A minus sign marks content that is in the original but not in the new version, so it was removed. A plus sign marks content that is only in the new version, so it was added. Lines with neither sign are unchanged and are shown for context.
Why is a whole line marked as changed when I only edited one word? Because a line diff compares whole lines. Any difference inside a line, even one letter or a trailing space, makes the old and new lines unequal, so the old one is shown as removed and the new one as added. A word-level diff would highlight only the changed word.
Why does the diff show differences I can't see? Something invisible differs: a trailing space, a tab instead of spaces, a non-breaking or zero-width space, curly instead of straight quotes, or a blank line at the end. Clean both texts the same way, then compare them again.
Can a diff detect moved text? A standard diff cannot. A moved block appears as a removal where it used to be and an addition where it is now. Some tools add move detection on top, such as git's --color-moved option, which colors moved lines differently.
What is the longest common subsequence? It is the longest sequence of lines, words or characters that appears in both versions in the same order, not necessarily side by side. A diff treats that sequence as unchanged and reports everything else as removed or added, which gives the fewest possible edits.
How do I compare two Word documents? Microsoft Word has a Compare command on its Review tab, and Google Docs has Compare documents in its Tools menu. To check the wording alone, copy the text of each version into a diff tool, and for PDFs use a tool that extracts the text before comparing.
All Code Formatters tools · All guides