“What changed?” is the most expensive question in computing, asked after every broken deploy, every contract revision, every “I only touched one line, I swear”. Eyeballing two versions side by side fails at exactly the moments it matters, because the dangerous changes are the invisible ones: a flipped flag, a missing comma, a space that became a tab. A diff answers the question mechanically and completely, and our free diff checker does it in your browser, where private configs and unsigned contracts belong.
In this guide
What a diff actually computes
A diff is not a vague similarity score; it is the precise minimal set of line insertions and deletions that turns text A into text B. The algorithm finds the longest run of lines the two versions share and reports everything outside it, which produces three categories: lines only in A (removed), lines only in B (added), and the unchanged context around them. One consequence is worth internalizing: a modified line appears as a removal plus an addition, because line-based diffing has no concept of “edited”, only of lines that exist in one version and not the other. Good tools soften this by highlighting the changed characters within such pairs, but the underlying report is always adds and removes.
Reading diff output fluently
Two display conventions cover the field. Side-by-side puts the versions in two columns with changes aligned, the natural view for humans comparing documents. Unified interleaves them in one column, removals marked with −, additions with +, the compact convention of code review and patch files. Reading fluency is three habits: scan the markers before reading prose (the shape of a diff, three lines here, forty there, tells you the blast radius first); read remove-add pairs together as “this became that”; and trust the count, if the tool says two changes, there are exactly two, and the feeling that “something else must have changed” is the eyeball error the diff exists to replace.
The invisible changes: whitespace and line endings
The diffs that confuse people are the ones that look empty: a line flagged as changed that reads identically on both sides. Three invisible culprits account for nearly all of them. Trailing spaces, present in one version and not the other. Tabs versus spaces, identical on screen at the right settings, different bytes. Line endings, the Windows-Unix divide where every single line can differ by one invisible character, producing the alarming everything-changed diff after a file crosses operating systems. The same invisible-character family that breaks list matching in the text cleanup pillar breaks diffs, and the response is the same: when a diff looks wrong, suspect the characters you cannot see, and use an ignore-whitespace option deliberately rather than by default, since in indentation-sensitive contexts whitespace is the change.
Preparing texts so the diff tells the truth
A diff is line-based, so the quality of the answer depends on the line structure of the inputs:
- Pretty-print before diffing structured data. Minified JSON or CSS is one enormous line, and any change diffs as “the whole line changed”, which is technically true and humanly useless. Format both versions first, with the JSON analyzer or the CSS formatter, and the diff collapses to the actual change.
- Format both sides identically. Diffing a formatted version against a minified one reports a hundred percent difference between identical data; whatever normalization you apply, apply to both.
- For prose, mind the paragraph. Reflowed text moves line breaks without changing words, lighting up a line diff. Comparing at one-sentence-per-line, or accepting paragraph-level granularity, keeps prose diffs honest.
The use cases beyond code
Diffing earned its reputation in programming, but the question it answers is universal. Contracts and terms: “the updated agreement” diffed against the version you signed shows precisely what the update is, which has a way of being informative. Configs before and after: capture the file before the change, diff after, and the deploy postmortem writes itself. Content versions: what an editor, a colleague, or a CMS migration actually altered. Generated output: two runs of the same export diffed reveal whether a system is deterministic, and where it is not. In each case the alternative is human attention, which is exactly the resource the dangerous tenth change escapes; the rest of the local-first toolbox for such work lives in the developer tools pillar.
Frequently asked questions
Can a diff tool tell me which version is newer?
No: a diff sees two texts, not their history. Order is metadata you bring; the tool reports differences symmetrically, and swapping the inputs just flips adds and removes.
Why does my diff show a change on every line?
Almost always line endings (the Windows-Unix divide) or one side being minified. Normalize both sides, same endings, same formatting, and the real diff emerges from the noise.
Is there a way to diff two Word documents or PDFs?
Extract the text first, then diff the text: for PDFs that is the text extractor, with the extraction caveats covered in the extraction guide. Formatting changes will not appear, content changes will, which is usually the question anyway.
What is the difference between diff and merge?
Diff reports differences; merge combines two versions into one, using diffs as its map and asking a human when both sides changed the same lines. Every merge tool has a diff inside it; the reverse is not required.