What people actually compare
Two versions of a config file before a deploy. A contract as sent against the contract as returned. Yesterday API response against today. A production environment file against staging. An export of a customer record before and after a migration. Almost none of it is public, and a fair amount of it is the kind of thing that should not acquire a copy on someone else infrastructure on its way to being read.
The comparison here is computed in the page. Both sides stay in the tab, there is no saved diff because there is nowhere to save one, and closing the tab is the entire retention policy. That is less capable than a service with history and sharing, and for an environment file containing live credentials it is the correct amount of capability.
When every line shows as changed
This is nearly always line endings. A file written on Windows ends its lines with carriage return and line feed; one written on Unix uses line feed alone. To a line-based diff those are different lines from the first character to the last, so the two files appear to share nothing even when the visible text is identical.
The other common cause is indentation - tabs converted to spaces by an editor, or the whole block re-indented by a formatter. Both produce a diff that is technically correct and entirely useless. Normalise line endings and whitespace before comparing, and the real change usually turns out to be three lines.
Comparing structured data needs a different move
Two JSON documents that describe exactly the same thing can differ on every line because the keys came out in a different order, or because one is minified. A line diff faithfully reports that as a complete rewrite, which tells you nothing.
Format both sides first, with sorted keys if your formatter offers it, and the diff collapses to the fields that actually changed. The same applies to YAML, to SQL dumps and to anything else where the serialisation has freedom the meaning does not.