Line Diff vs Word Diff: Comparing Config Files and Comparing Paragraphs

Diff checker's two modes aren't a stylistic preference - they answer genuinely different questions, and picking the wrong one either buries you in irrelevant noise or hides the exact change you actually needed to see.

Line mode: built for structured, line-oriented content

A config file, a script, a piece of code, or any document where each line is its own meaningful unit wants line mode. It tells you exactly which lines were added, removed, or changed, matching the convention every developer already recognizes from git diff and every code review tool. Crucially, a line that changed even slightly is shown as fully removed-then-added rather than partially marked - which is the right level of detail for code, where "this line is different" already tells you where to look, and word-level noise inside a line you're about to re-read in full just adds clutter.

Word mode: built for prose where the exact wording is the point

A paragraph, a sentence, an email draft, a contract clause - anything where the content is continuous prose rather than discrete lines wants word mode instead. It shows precisely which words were added or removed inside a passage that's otherwise identical, which is the entire point when comparing two drafts: you don't want "this paragraph changed," you want to see the exact three words that were swapped.

A concrete example: comparing two drafts of an email

Paste your first draft as Original and your edited version as Changed, switch to Word mode, and the result shows precisely which phrases were reworded - "will follow up next week" becoming "may follow up next week," say - inline, in the sentence's own reading order. Reading the two drafts side by side would very plausibly miss that single changed word; word mode can't.

A concrete example: comparing two versions of a config file

Paste the old config as Original and the new one as Changed in Line mode, and the result shows exactly which settings were added, removed, or altered - a changed timeout value, a new environment variable, a removed feature flag - each as its own line, with everything unchanged left alone. This is the check worth running before deploying a config change you didn't write yourself, or before merging one you did.

Comparing an AI-rewritten paragraph against the original

If a tool or a colleague rewrote a paragraph for you, Word mode is the fastest way to see exactly what changed in meaning versus phrasing - a rewrite that "sounds similar" can still add a claim that wasn't there, drop a caveat that was, or subtly change a number. Diffing the before and after is a genuinely useful habit for exactly the reason covered in the background piece: reading both versions and trusting your impression isn't the same as knowing precisely what changed.

What neither mode does: character-level diff

Word mode is the finest grain this tool offers - it won't show you that a single character inside one word changed (a typo like "recieve" corrected to "receive" shows as the whole word swapped, not one letter). For most real text that distinction rarely matters; for comparing something like a URL, an ID, or a short code string character by character, a word-level diff is still the closest tool here gets, and it's worth reading the highlighted word carefully rather than expecting a letter-level callout.

Trying both modes when you're not sure

If you genuinely don't know which mode fits - a mixed document with both prose and a code block, say - it costs nothing to check both. Line mode on mixed content will show entire lines as changed even for a one-word edit inside a long paragraph line; Word mode on genuine code can get noisy on a line where indentation or punctuation shifted for reasons that don't matter. Switching between them takes one click and neither clears your pasted text, so trying both before deciding which result you actually want to read is a completely reasonable first step, not a sign you picked wrong.

A borderline case: a short, structured line inside otherwise free text

A single changed line inside a mostly-prose document - a date stamp, a reference number, a status line - sits right at the boundary between the two modes. Line mode correctly isolates it as one changed line among many unchanged ones, which is often exactly what you want; Word mode would show the same change but folded into the surrounding prose's own word-level view. Neither is wrong here - it depends on whether you want "which line changed" or "which specific words changed," and for a single structured line, those two answers often look nearly identical anyway.

The two modes, side by side one more time

Line mode: whole lines, added or removed, matches the convention every developer already knows from version control. Word mode: individual words, added or removed, inside lines that stay otherwise intact. Neither mode is more "correct" in the abstract - the right one is whichever matches the actual unit of meaning in what you're comparing, a line of config or a word in a sentence.

For the actual steps, see the how-to guide. Or compare your own two texts now.