About the Text Diff Checker
This text diff checker compares an original and a changed version line by line and marks each line as unchanged, removed or added, with counts for each and a straight yes-or-no verdict on whether the two texts are identical. The comparison uses a longest common subsequence algorithm, so a paragraph inserted in the middle is reported as an insertion rather than knocking every following line out of alignment. Two options adjust what counts as a difference: ignoring letter case, and ignoring leading and trailing whitespace, which is on by default because indentation churn is rarely what you are looking for. Both texts stay in your browser throughout.
How to use the Text Diff Checker
- 1
Paste the earlier version into the Original box.
- 2
Paste the newer version into the Changed box.
- 3
Leave 'Ignore leading/trailing spaces' ticked to hide pure indentation changes, or untick it when whitespace matters.
- 4
Tick 'Ignore letter case' when comparing text where capitalisation is not significant.
- 5
Read the Differences summary, then work down the 'Line by line' table where a minus marks a removed line and a plus an added one.
What people use it for
Finding what changed between two config files
Comparing a working environment file against a failing one usually locates the single differing value faster than reading either file end to end.
Checking an edited document against the original
When a contract or a brief comes back without tracked changes, a line diff shows exactly which clauses were touched and which were left alone.
Comparing two API responses
Format both payloads with the JSON formatter using sorted keys first, then diff them; the only differences left are genuine value changes.
Verifying a copy or a migration
Diffing exported records from before and after a move confirms nothing was silently dropped, truncated or reordered along the way.
The longest common subsequence algorithm behind the diff
A subsequence keeps the order of a sequence but may skip elements, so the longest common subsequence of two files is the largest set of lines appearing in both in the same relative order. Those lines are the unchanged ones: everything in the original but not in the subsequence was deleted, and everything in the new version but not in it was added. The classic solution is dynamic programming. Build a table where each cell holds the LCS length of the two suffixes starting at that pair of positions. If the two lines are equal, the cell is one more than its diagonal neighbour; otherwise it is the larger of the neighbour below and the neighbour to the right. Filling the table takes time and memory proportional to n times m for files of n and m lines, after which walking back through it emits the edit script. Git and most modern tools use Myers' 1986 algorithm instead, which runs in time proportional to n times d where d is the size of the difference — far faster when two large files are nearly identical, the normal case in version control — but it produces the same minimal edit script the table does.
Why the diff is line based, and what that misses
Working at line granularity is what makes the algorithm practical and its output readable, but it has consequences. Changing one character in a long line reports that line as fully removed and fully added, with no indication of which word moved; character-level and word-level diffs solve that at the cost of much noisier output on real edits. A block of text moved from the top of a file to the bottom appears as a deletion followed by an unrelated insertion, since LCS preserves order by definition and has no way to express a move — git only detects those through heuristics layered on top. Line endings matter too: a file saved with Windows CRLF endings diffs as entirely changed against the same content saved with Unix LF endings, which is one reason the ignore-whitespace option is on by default here. And when two files share no unchanged lines at all, the LCS is empty and every line is reported as both removed and added, which is technically correct but rarely useful.
Tips
- Normalise both sides first — sort keys, format the code, unify line endings — so the diff shows meaning rather than formatting.
- For very long lines, split them at a natural boundary before diffing so the change is narrowed to a smaller unit.
- An 'Identical: Yes' verdict with the whitespace option enabled still permits indentation differences; untick it for a byte-exact check.