What a real diff algorithm buys you over a naive comparison
The naive way to "diff" two texts is comparing line 1 to line 1, line 2 to line 2, and so on. That falls apart the moment a single line gets inserted near the top: every line after it now looks completely different from its counterpart, even though nothing past the insertion point actually changed.
This tool computes the longest common subsequence (LCS) between the two texts — the largest set of lines that appear in the same relative order in both — and treats everything else as an addition or a removal around that shared backbone. It is the same category of algorithm Git and most version control diffs are built on, not a coincidence: it is the algorithm that actually answers "what changed" correctly.
Why a single edited line shows as remove-then-add, not "changed"
A line-based diff has exactly two primitive operations: a line is either present in both, or it is added, or it is removed. There is no third "modified" operation, because the algorithm has no concept of similarity between two different lines — only exact-match or no-match.
So editing one word in a line shows up as that whole line being removed and a new, mostly-similar line being added right after it. This is standard behaviour for line-level diffing tools generally, not a limitation specific to this one — word-level or character-level diffing is a different, more granular algorithm applied within a line, which this tool does not attempt.
What counts as a changed line
Comparison is exact per line: whitespace, capitalization and punctuation all matter. Two lines that a person would call "basically the same" but differ by a trailing space are counted as fully different lines by this algorithm, the same way git diff would treat them.
Line endings are normalized before comparing, though — Windows-style \r\n and Unix-style \n are treated as equivalent, so switching a file's line-ending convention alone does not manufacture a wall of false differences.
When line-level diffing is and is not the right tool
It is exactly right for code, configuration files, structured logs, and anything organized into meaningful lines — which is most of what developers actually diff. It is a poor fit for flowing prose with no fixed line breaks, since the "lines" in that case are really just wherever a paragraph happened to wrap, and a diff of wrap points is not a diff of meaning.