Paste two versions of a text, hit Compare, and read a unified diff with separate line-number gutters for each side. The comparison runs on a longest-common-subsequence table, the same family of algorithm behind git diff,.
How to read the two-gutter output
The left gutter carries the original file's line numbers, the right gutter the modified file's. A removed line has only a left number and a minus prefix; an added line has only a right number and a plus. Above the table, three counters summarize the result: lines added, lines removed, and lines unchanged. If both inputs are identical, every line renders as unchanged context and the counters read +0 and -0, so you get positive confirmation of a match instead of guessing at a blank panel.
One convention worth internalizing: a changed line never appears as 'changed'. It shows up as a remove-add pair, because the diff compares whole lines for exact equality. Changing 'timeout = 30' to 'timeout = 300' produces one removed line and one added line, and the counters report -1/+1 even though you only typed a single character.
Where line-based diffing bites
Equality is exact, so invisible differences count. A trailing space, a tab-vs-spaces mismatch, or CRLF line endings on one side will mark otherwise identical lines as removed and re-added. There is no ignore-whitespace toggle here, so normalize both sides first if that noise matters. There is also no intra-line highlighting: for spotting a one-word edit inside a long paragraph, reflow the text so each sentence sits on its own line before comparing.
The LCS table costs memory proportional to (lines in A) x (lines in B). Two configs, two SQL dumps of a few hundred lines, two versions of an article: instant. Two 50,000-line log files: that is 2.5 billion table cells, and the tab will stall. Split big comparisons into sections.
If the two blobs are JSON, run both through the JSON formatter first so the diff shows real changes instead of formatting noise. The XML formatter does the same job for XML payloads.