Comparing drafts before you publish

The changes that cause the most trouble are the ones nobody meant to make — a paragraph deleted while accepting someone else’s edit, a figure altered during a find-and-replace, a sentence that reverted when two people saved over each other. A diff catches these before a reader does. It is the difference between reviewing what you think changed and seeing what actually changed, which are rarely the same thing.

Why the eye misses edits

Reading two versions in sequence does not work, because you know what the text is supposed to say and your eye fills in the rest. You skim past a dropped “not” that inverts a sentence. You miss a number that shifted from 40 to 400. Proofreading finds new errors; it is poor at finding differences between two things you have both read many times. A diff removes the memory from the equation by showing only what moved.

This matters most at the moments when text passes between hands or tools: after a co-author’s round of edits, after pasting a piece back out of a CMS, after a translation, or after any bulk operation you ran across the whole document. Each of those is a chance for a silent change, and each is exactly when a comparison pays off.

Line diff or word diff

The two granularities answer different questions. A line diff compares whole lines and shows a changed line as a deletion of the old and an addition of the new. It is the right choice for structured content — a list, a config file, code, or anything where a line is a meaningful unit — because it keeps each entry as one thing you can scan.

A word diff compares within lines and highlights only the words that changed inside an otherwise unchanged sentence. This is what you want for prose. When someone has swapped one adjective or fixed a typo mid-paragraph, a line diff flags the entire paragraph as changed and buries the edit; a word diff points straight at the single word. Match the granularity to the content and the real change stops hiding.

• Prose, where edits are words inside sentences: use a word diff.
• Lists, tables, and code, where a line is one item: use a line diff.
• A paragraph that a line diff flags as wholly changed: switch to word view to find the actual edit.
• A long document with edits scattered through it: start with line view for the map, then word view on the sections it flags.

Ignoring what you don’t care about

Not every difference is a real change. Text that has passed through different editors picks up cosmetic variation — a run of spaces collapsed to one, a tab that became spaces, a line that wrapped differently, a capital letter at the start of a sentence you rewrote. If the diff marks all of these, the meaningful edits drown in noise.

Turning on the options to ignore whitespace and letter case strips out the cosmetic differences and leaves the substantive ones. Use them when the two versions came from different tools and you only care whether the words changed. Turn them off when spacing or case is itself the thing you are checking — a code file where indentation matters, or a title where capitalisation is the point.

Split view versus unified

A split view puts the two versions side by side, old on the left and new on the right, which suits a close comparison where you want to see each version whole. A unified view stacks the changes inline, marking deletions and additions in one column, which reads more like a changelog and works well when the edits are sparse and you want a compact summary of them. Neither is more correct; pick the one that matches how you want to read the change.

A pre-publish routine

A reliable final check takes two minutes. Keep the last version you fully trusted — the one you proofread, or the one before the co-author’s pass. Diff it against the version you are about to publish. Read the additions and deletions rather than the whole document: those are the only parts that changed, so those are the only parts that can carry a new mistake. Confirm each change was intended, and only then ship.

If you draft in Markdown, comparing the raw source rather than the rendered output gives a cleaner diff, because formatting marks show up as text you can see rather than invisible styling. Keeping a plain-text or Markdown copy of each milestone makes this routine painless.

The comparison runs entirely in your browser, so two versions of a confidential contract, an embargoed announcement, or an unpublished manuscript are not uploaded anywhere to be compared. Both texts stay on the page.