How to compare two texts line by line

You have two versions of a paragraph, a config file, a translation — and you need to know exactly what changed. A line diff is the fastest way to get that answer, and you do not need to install anything to run one.

What a line diff actually does

A line diff splits both inputs on \n, finds the longest sequence of lines that appears in both, and labels everything else as "added on the right" or "removed from the left." The longest-common-subsequence algorithm (LCS) is the standard way to do this — it has been the bones of diff, git diff, and every code-review interface since 1976.

That means two things in practice:

1. Two lines either match exactly or they do not. Identical leading whitespace counts as a match. Trailing whitespace does not. If you are diffing something with mixed indentation, normalize the indent first or the diff will be noisy.
2. The algorithm finds the "minimum edit" path. If you delete a 5-line block and add a different 5-line block in the same spot, you get 10 changes — 5 deletes and 5 inserts. The tool does not try to detect "this was edited from that."

A typical workflow

1. Open the Text Diff Checker.
2. Paste the original version on the left. The new version on the right.
3. Read the summary chips at the top: added, removed, unchanged.
4. Toggle "show unchanged lines" off when the file is long — you only want to see what is different.

The colors mirror what every code-review tool uses: green for "this line is in the new version only," red for "this line is in the old version only." Neutral lines exist in both.

Three gotchas that ruin diffs

Trailing whitespace differences. A line that ends with one extra space is, technically, a different line. If your editor trims trailing whitespace on save (most do; some don't), you can end up with diffs that highlight invisible changes. Run both texts through the whitespace cleaner first if you don't care about those.

Reordered lines. If you reorganize a list, every moved line shows as a delete + insert, even though nothing was "edited." Line diffs cannot detect moves. For that you need a structural diff (or a human eye).

Big inputs. The LCS algorithm is O(n × m). For two 50-line texts that is 2,500 comparisons — instant. For two 5,000-line texts that is 25 million — still fast in 2026 but you will notice a brief pause. Truncate to the section you care about for large files.

When to reach for a different tool

• Diffing JSON or YAML? Format both sides first with the JSON formatter. Otherwise a single key reorder creates a giant noisy diff.
• Diffing source code? Run both through a real git diff if you can. Git knows about renames, moves, and hunks.
• Diffing translations? A word-level diff (not a line diff) reads better. For now the closest thing here is to put each sentence on its own line on both sides.

For the 80% case — comparing two paragraphs, two configs, two prompt versions — the line diff is the right shape.