Text Diff Checker
Find added and removed lines between two versions, side by side
How text diffing works: the LCS algorithm, line-level comparison, and noise
Why compare by line, not by character
Character-level diff, when a single character in a line changes, pinpoints exactly which characters moved; but on structured text — code, configuration, CSV — character-level diff produces meaningless fragments. Changing a trailing comma into a newline makes the character diff flag the whole line as changed, while a human wants to see "this line changed".
Line-level comparison is the default engineering choice: each line is an indivisible unit, and the output is "which lines were deleted, which were added, which stayed the same". This is the same granularity used by git diff, diff -u, and code-review interfaces.
LCS: how "fewest lines changed" is computed
The core of line-level diff is the Longest Common Subsequence. The idea: find the longest line sequence that both versions share in the same order; those lines are "unchanged", and the rest are insertions or deletions.
For example, the original three lines are A B C and the new three lines are A C D:
| Result | Explanation | |
|---|---|---|
| Common subsequence | A C | Same order, both present, length 2, and this is the longest |
| Deleted | B | Only in the original |
| Added | D | Only in the new version |
The algorithm fills an n×m table with dynamic programming (n and m are the line counts of the two versions) and then backtracks to recover the subsequence. So the cost grows as the product of the line counts: two 1000-line files need about a million comparisons, which is fast; two 100,000-line files need ten billion, which is noticeably slow. This tool's table method is exactly that complexity — it handles tens of thousands of lines comfortably, but for larger files prefer git diff or a specialized diff library (they usually add block pre-filtering to skip unchanged regions).
It cannot detect "moved"
This is an inherent limit of LCS-class algorithms: moving a paragraph from the start of a file to the end is reported as "deleted at the start" plus "added at the end", not as "moved".
The consequence is that refactor-style changes (reordering functions, regrouping configuration) look like massive edits even though the logic is unchanged. Some advanced diff tools do move detection (pairing identical blocks and labeling them moved), but that needs extra heuristics and can misjudge too. When you see a large block of red and green, first ask whether it is purely a reordering.
Noise sources and how to handle them
| Noise | Symptom | Handling |
|---|---|---|
| Trailing-whitespace differences | An entire line flagged as changed, invisible to the eye | Strip trailing whitespace before comparing |
| Mixed tabs and spaces | Indentation looks identical but is actually different | Unify the indent character, or use a whitespace-ignoring compare mode |
| Newline differences | The whole file flagged as different | CRLF (Windows) and LF (Unix) must be unified |
| File-encoding differences | All Chinese garbled or all marked red | Confirm both sides are UTF-8 (and that the BOM presence matches) |
| Reformatting | Every line differs yet content is equivalent | Run a formatter first, then compare, or compare the formatted result |
The third row is the easiest to trip on: one file saved with a Windows editor and another exported on Linux may have identical line content yet each carries a trailing \r, so the result is all red — it looks like "everything changed" when it is only the newline. This tool compares by exact line content, so when you see "all red but no visible difference", check the newline first.
Practical techniques
- Normalize before comparing. Unify newlines, strip trailing whitespace, and unify indentation. This removes the vast majority of false diffs and lets the real changes stand out.
- Sort structured data before comparing. For JSON, CSV, and properties, line order carries no meaning (or can be agreed upon), so sorting first drops the difference from hundreds of lines to a few.
- Split large files into batches. Cut by feature block or time range, then compare block by block. Looking at a 5000-line diff at once is meaningless; the human eye cannot judge it.
- Remember diff is bidirectional. Red (deleted) is not necessarily wrong and green (added) is not necessarily right — the business intent decides, not the color.
- Use it for config verification. Diffing two environments' configuration is the most intuitive use; it directly reveals problems like "production has an extra switch".
How to use the tool
- Put the original (old) text on the left and the comparison (new) text on the right, one entry per line.
- Click Compare; the output marks deleted lines, added lines, and unchanged lines in three categories.
- The legend sits below the button, mapping color to meaning.
Comparison runs locally in your browser; neither version of the text is uploaded, which is a necessary precondition when comparing files that contain customer data, secrets, or internal configuration.
FAQ
What is the comparison algorithm?
A line-by-line diff based on the Longest Common Subsequence (LCS), which stably finds added, removed and unchanged lines, ideal for version comparison.
Why are some lines marked removed instead of modified?
The tool compares by whole lines; a changed line is treated as "old line removed + new line added" and does not do intra-line character-level comparison.