When everything is marked as changed
A comparison where almost every row is flagged, after an edit you know was small, is nearly always correct and nearly always useless. Something mechanical has changed on every line — the indentation, the capitalisation, the way lines were wrapped — and the comparison is dutifully reporting all of it alongside the three changes you care about.
There are two different tools for this, and knowing which is which saves a lot of confusion. One changes how the engine compares text it leaves alone. The other edits the text in the panels. They are in different places on the page for that reason.
Case sensitive: the switch that changes the comparison
The Case sensitive switch sits with the comparison settings and is on by default. With it on, capitalisation counts as a difference. Turn it off and capitalisation is ignored, in both Smart and Strict modes, and your text is not touched — flip it back and the previous result returns.
On is the right default and the reason is worth stating. Value and value are genuinely different things in code, in environment variables, in anything where a name has to match exactly. Defaulting this off would score two files as a perfect match while the panels visibly disagreed, with nothing on screen naming the setting responsible.
Turn it off when capitalisation is not significant to what you are checking: two drafts of prose where a sentence was recapitalised after a rewrap, a list of keywords that got title-cased, a query someone reformatted. It is one click and costs nothing, so it is worth trying before you conclude a document was heavily rewritten.
The transforms: when you want the text itself changed
Below the panels, once there is text in them, is a row labelled Transform both sides with two buttons. To lowercase folds everything down. To sentence case folds everything down and then capitalises the first letter of each sentence.
These edit what is in the panels — you can see the result — which is a real difference from the switch above. Both apply to both sides at once, deliberately: the reason to fold case is almost always to stop it registering as a difference, and that only works if it happens symmetrically.
Sentence case is the more useful of the two for prose. Lowercase flattens capitalisation out of the comparison entirely; sentence case normalises it, so a paragraph that got recapitalised after a rewrap stops registering while the capitals a reader expects at the start of a sentence survive. It is blunt about abbreviations by design — "e.g. the thing" becomes "e.g. The thing" — because recognising which full stops end a sentence needs a per-language abbreviation list, and predictable beats clever in a tool whose output you have to reason about.
Both transforms discard information: nothing records which letters were capitals, so transforming to the other case is not a way back. Use the Undo button that appears beside them, which restores the text from before the transform ran.
Whitespace: there is no switch, and what to do instead
Being direct about this, because it is the most common thing people go looking for: there is no option here to ignore whitespace. Indentation, trailing spaces, tabs versus spaces, and the way long lines were wrapped are all read as part of the text, so changing them changes the comparison.
The fix is to normalise both sides before comparing rather than asking the comparison to look past it. For code, run the same formatter over both versions and compare the results. For prose, if one side was rewrapped, rewrap both the same way. The differences that survive are the ones you were actually looking for.
This is more reliable than an ignore-whitespace setting would be, which is some consolation. Ignoring whitespace hides real changes to string literals, and in Python or YAML indentation is syntax, so a comparison that discarded it would be concealing changes that alter meaning. A formatter produces one canonical form and hides nothing.
Line endings: not the problem, despite the reputation
This one is worth clearing up because it is the usual suspect and it is innocent here. Windows line endings (\r\n), Unix line endings (\n), and classic-Mac ones (a lone \r) are each treated as a single line terminator, and a line's content is taken to exclude its terminator. A file saved on Windows and the same file saved on Linux compare as identical.
A trailing newline at the end of a file is likewise not a difference. The terminator ends the final line rather than starting a new empty one, so a file that ends with a newline does not report a phantom added blank row at the bottom.
So if a comparison is showing differences you cannot see, line endings are not the explanation. Invisible characters that are real differences include trailing spaces at the ends of lines, tabs where you expected spaces, non-breaking spaces pasted in from a web page or a word processor, and zero-width characters. Those are genuine textual differences and the tool is right to report them.
A quick order of operations
When a result looks noisier than the edit deserves, work through it in this order. Turn Case sensitive off and see whether the picture clears — it is free and reversible. If the noise is indentation or wrapping, normalise both sides outside the tool and paste again. If prose was recapitalised, use To sentence case on both sides.
If the remaining changes are correct but each one is being reported twice — once as a deletion and once as an addition — that is a different problem with its own page: see moved and reordered blocks. And if you are not sure what the categories and the score are telling you in the first place, how to read a diff is the place to start.