How the comparison works
This tool compares your two texts one line at a time, the same unit that git diff, Google Docs version history and most code review tools use. It first splits both sides on line breaks, then finds the longest common subsequence of lines: the largest set of lines that appear in both documents in the same order, though not necessarily next to each other. Everything in that common set is reported as unchanged. Every line from the left side that is not in it was removed, and every line from the right side that is not in it was added.
The longest common subsequence is computed with a dynamic-programming table of m x n cells, where m and n are the line counts. That is exact rather than approximate, but it also means the work grows with the product of the two lengths, which is why the tool caps each side at 800 lines. Everything runs in your browser as plain JavaScript, so contracts, medical notes, source code and anything else you paste never leave your computer and nothing is stored.
Options and how to read the output
Ignore leading and trailing spaces is on by default. It strips spaces and tabs from the start and end of each line before comparing, so a re-indented paragraph or a stray trailing space does not show up as a change. Ignore case treats Net 30 and net 30 as the same line, which is handy when comparing exports from two systems that capitalize differently. Hide unchanged lines collapses the matching text so long documents show only the edits. In every case the original text is displayed exactly as you typed it; the options only affect the matching.
Lines that begin with a green + exist only in the changed text, and lines with a red - exist only in the original. A line that was edited in place appears as a pair: the old version in red immediately followed by the new version in green. In the sample above, the date line, the delivery line and the signature each show as one removal plus one addition, the warranty sentence shows as a single addition, and the summary reports 4 added, 3 removed, 4 unchanged.
Practical uses and limits
Typical jobs: checking what a client changed in a redlined contract, confirming that a vendor CSV export matches last month's, spotting an accidental edit in a blog post before publishing, and comparing two error logs. For text that is one long paragraph per line, a line diff will flag the whole paragraph even if a single word changed, so break prose into sentences first if you need finer detail. Word-level and character-level diffs are better for that, and dedicated merge tools are better when you actually need to combine both sides.
One caveat about moved blocks: if you cut a paragraph and paste it 20 lines lower, a line diff reports it as a deletion plus an addition rather than a move, because the order changed. That is standard behavior for every line-based diff, including git.