Your eye is very good at reading and very bad at comparing. It fills in what it expects, skips repeated words, and slides over a changed number in a paragraph you have already read four times. This is the same mechanism that makes proofreading your own writing so difficult, and it does not improve with effort.
A comparison tool has the opposite properties. It cannot read at all and it never skips.
What a diff actually computes
The question a diff answers is narrow and precise: what is the shortest set of insertions and deletions that turns the first text into the second?
It works by finding the longest sequence the two versions have in common — not necessarily contiguous — and treating that as the unchanged spine. Everything in the first text that is not on the spine was deleted; everything in the second that is not on it was added.
That framing explains most of the surprising behaviour. A diff has no idea what a sentence is, or a paragraph, or a meaning. It knows which pieces both sides share.
Why a moved paragraph looks like a rewrite
Move a paragraph from page one to page three and the diff reports a large deletion and a large addition, because the shortest edit script genuinely is to remove it from one place and insert it in the other. There is no "moved" operation.
Some tools detect moves afterwards by noticing that a deleted block matches an inserted one, and present them as a move. That is a layer of interpretation added on top, and it is worth knowing which behaviour you are looking at, because a tool without it will make a reorganised document look completely rewritten.
Line, word, or character
Line comparison treats each line as a unit. Change one word and the whole line is marked. This is correct for code, where a line is a meaningful unit, and unhelpful for prose, where a paragraph is often a single very long line — fix one typo and the tool reports the entire paragraph as changed.
Word comparison highlights the words that moved and leaves the rest alone. For two drafts of the same document this is almost always what you want.
Character comparison goes finer still, which is useful for a reference number or a hash where one digit matters, and produces confetti on anything longer.
A text comparison that lets you choose is worth more than one that picks for you, because the right granularity depends entirely on what you are comparing.
When it says everything changed
This is the most common complaint and it is almost never the tool.
Line endings. Windows ends a line with two characters, Unix with one. A file that has travelled between the two differs on every line by something you cannot see. This accounts for the large majority of "the diff is broken".
Trailing whitespace. An editor that trims line ends on save, comparing against one that does not.
Tabs and spaces. One side re-indented.
Invisible characters. Non-breaking spaces from a word processor, a byte order mark at the start of one file — the same family of problem that breaks searching.
All four are solved the same way: normalise both sides first. Run each through a whitespace cleaner, then compare. If the noise disappears, you have learnt what the difference actually was.
What it will not tell you
A diff will not tell you whether the change matters. Two texts with one word different may differ in meaning entirely — shall and may in a contract — and two texts with a hundred differences may say the same thing in a different order.
It is also not a similarity measure and not a plagiarism check. It answers "what edits connect these", and a document that was paraphrased throughout will show as almost entirely changed while being substantially the same work.
The cases it is best at
A contract or agreement returned with edits. The classic use, and the one where the eye fails most expensively. Word comparison, both sides normalised first.
Two exports of the same data, to see what a process changed. Line comparison, sorted first if the order is not meaningful — otherwise a reordering swamps the real difference.
A configuration that worked and one that does not. Line comparison, and the answer is usually visible immediately.
Two drafts of your own writing, to see what an editor did. Word comparison.
In every one of these the input is something you would rather not paste into a website that processes it on a server, which is a good reason to do it in the browser: contracts and configurations are precisely the documents this problem arises for.
The short version
Normalise both sides before comparing, or line endings will hide the answer. Choose word comparison for prose and line comparison for code. Expect a moved block to appear as a deletion and an addition, because that is what it is.
And do not read the two versions yourself to check the tool. That is the thing you already know does not work.