Why LCS instead of a naive line-by-line comparison

Comparing text line 1 to line 1, line 2 to line 2, and so on breaks the moment a single line is inserted or removed anywhere but the very end — everything after that point looks "changed" even though it's identical, just shifted. This tool instead finds the Longest Common Subsequence between the two texts: the largest set of lines that appear in both, in the same relative order, whether or not they're adjacent. Everything in that common subsequence is marked unchanged; everything else is marked as removed (only in the original) or added (only in the modified). That's the same underlying idea behind `diff` and `git diff` — it's why inserting one line in the middle of a large file produces a small, readable diff instead of the entire tail of the file being flagged as changed.

What counts as "different"

Lines are compared for exact equality, which includes whitespace — a line with a trailing space is a different line from the same text without one. This is deliberate: for config files, code, and structured text, whitespace differences are frequently the actual bug being hunted for, so silently ignoring them would hide the thing you're trying to find. If whitespace noise from an unrelated reformatting is drowning out the diff you actually care about, trimming both inputs to consistent formatting before pasting is the workaround.

When to reach for this instead of `git diff`

If both versions already live in a Git repository, `git diff` will always be more capable — it understands file moves, renames, and hunks natively. This tool is for the case Git doesn't cover well: comparing two blobs of text that don't live in version control at all, like two API responses, two versions of a config pulled from different servers, or a before/after paste from a chat conversation, without needing to create files or a repo just to see what changed.