Why comparing by eye fails in a specific way
Reading two versions side by side catches the large changes and misses the small ones, and the small ones are usually what matter. A rewritten paragraph is obvious. A figure changed from 45,000 to 54,000, a deadline moved from 30 days to 15, or a removed "not" in a clause about liability are all invisible to a reader who already knows roughly what the document says — because the eye reads what it expects.
This is not carelessness. It is how reading works: you sample a familiar text rather than processing every character, which is exactly the efficiency that makes proofreading your own writing so unreliable. A mechanical comparison does not sample. It reports every difference regardless of how plausible the surrounding text looks.
The consequence is that comparison is most valuable precisely when you are most confident nothing important changed. A document returned as "the same with a couple of tweaks" is the one worth checking, because the description of what changed came from the person who changed it.
How the comparison works
The two texts are split into lines, and the tool finds the longest sequence of lines they have in common. Everything inside that sequence is unchanged; everything outside it is reported as removed from the original or added to the new version. This is the same model git and most code review tools use, and it is why the result reads as a set of edits rather than a list of every line that moved position.
Within a line that changed, a second comparison runs over the individual words, so only the words that actually differ are highlighted. Without that step a line where one number changed would be flagged red in its entirety, and you would be back to hunting for the difference yourself.
One consequence worth understanding: a block of text that moves is reported as a deletion in one place and an addition in another, because it genuinely is absent from its old position and present in a new one. You can tell a move from a rewrite by the unchanged count, which stays high for a move and drops for a rewrite.
Ignoring whitespace and case, and when not to
Ignoring whitespace collapses runs of spaces and tabs and trims each line before comparing. It is the right setting when a document has been reformatted, a paragraph reflowed, or a block of code reindented, since none of those change meaning and all of them otherwise flood the result with differences that tell you nothing.
It is the wrong setting when whitespace carries meaning. Indentation is syntax in Python and YAML, trailing spaces are significant in Markdown line breaks, and in fixed-width data files column position is the entire structure. Turning the option on in those cases hides real differences.
Ignoring case is narrower in use. It helps when comparing text that has been through a system that normalises capitalisation, or when checking whether two lists contain the same entries. For prose it is usually better left off, since a change from "may" to "May" is rarely accidental and a change in a defined term — Agreement versus agreement — can carry real legal weight.
What people actually use this for
Contract review is the highest-stakes case. A draft goes out, comes back, and the covering email describes two amendments. Comparing takes a minute and answers definitively whether there were two. Keeping the version you sent, clearly named, is what makes this possible — the usual reason a comparison cannot be done properly is that nobody kept a definitive copy of what went out.
Code and configuration are the highest-volume case. Comparing two versions of a config file to find why one environment behaves differently, checking what a colleague changed, or working out which of two similar-looking files is the one currently deployed are all faster to answer here than by reading both.
Then there is the everyday case: two files with different names and dates sitting in different folders, and the question of whether they are the same document or two versions. Paste both and you have an answer in seconds. If you only need to know whether two files are byte-for-byte identical rather than what differs, comparing their hashes is faster still.
Why this one runs in your browser
The things people compare are disproportionately the things they should not upload. Contract drafts before signature, configuration files containing credentials and connection strings, unreleased copy, source code, internal policy documents, and medical or financial records being checked against a corrected version.
Every one of those is more sensitive than the average file, and a comparison tool that uploads receives both versions — which is strictly more information than either version alone, because the differences between drafts often reveal the negotiation itself.
Here the comparison is computed in your browser with JavaScript. Nothing is transmitted, nothing is stored, and the page continues to work if you disconnect after loading it. For a tool whose entire purpose is examining documents at their most sensitive moment, that seems like the only defensible design.