Why does an inserted line not make everything after it look changed?

Because it compares by longest common subsequence rather than line by line. The naive version pairs line one with line one and so on, so a single insertion at the top reports every subsequent line as different and the output is useless exactly when you needed it. This finds the longest run of lines common to both, in order, and everything outside it is what was added or removed.

What does ignoring whitespace actually compare?

It trims each line and collapses runs of spaces before comparing, so an indentation change or a double space does not register. The output still shows your original lines, because a tool that silently rewrote your text would be a worse failure than one that is too sensitive.

How large a comparison will it do?

Five thousand lines a side. The algorithm needs a table of one cell per pair of lines, so the cost grows with the product of the two sizes rather than their sum. The limit is stated up front rather than discovered by whoever pastes two large files.

Text Diff

What changed, as a real diff.

Original

Changed

Ignore whitespaceYes

Ignore caseYes

What changed, as a real diff.

How to use it

Paste both versions. Any line endings. Windows and Unix files compare correctly.
Set what to ignore. Whitespace and case, when the difference is not meaningful.
Read the diff. Standard unified format, so it can be pasted into anything that reads a patch.

When you would use this

Comparing two versions of something is the most common reason to want a diff, and the naive implementation is wrong in a way that is obvious the first time you hit it. Comparing position against position works until a line is inserted. From that point on every line is offset by one, so every one of them is reported as changed, and the output is at its least useful precisely when the change was biggest. The right answer is the longest common subsequence: the longest run of lines that appears in both versions, in order but not necessarily adjacent. Everything outside that run was added or removed. It is what git computes and it is why a one line insertion shows as one insertion. Output is the unified format, the same one a patch file uses, with three lines of context around each change. That means it can be pasted into anything that reads a diff rather than only being readable here. Ignoring whitespace or case changes what is compared and never what is shown. The lines in the output are your originals, because a tool that quietly rewrote your text would be worse than one that flagged a change you did not care about.

Questions

Why does an inserted line not make everything after it look changed?: Because it compares by longest common subsequence rather than line by line. The naive version pairs line one with line one and so on, so a single insertion at the top reports every subsequent line as different and the output is useless exactly when you needed it. This finds the longest run of lines common to both, in order, and everything outside it is what was added or removed.
What does ignoring whitespace actually compare?: It trims each line and collapses runs of spaces before comparing, so an indentation change or a double space does not register. The output still shows your original lines, because a tool that silently rewrote your text would be a worse failure than one that is too sensitive.
How large a comparison will it do?: Five thousand lines a side. The algorithm needs a table of one cell per pair of lines, so the cost grows with the product of the two sizes rather than their sum. The limit is stated up front rather than discovered by whoever pastes two large files.