To compare two documents, place the earlier version and the later version side by side and run a difference (diff) algorithm over them: it marks every passage as added, removed, or unchanged. The decision that changes everything is the unit you compare by. Line mode treats each line as an indivisible block, word mode compares token by token, and character mode compares letter by letter. For reviewing prose — contracts, policies, articles — word mode is usually the right default: it pinpoints the exact edits a reviewer must judge, where line mode over-reports and character mode drowns the real changes in noise. Our free Text Compare tool offers all three modes, with side-by-side and inline views and a summary count. This guide explains how diffing works, proves the mode difference with one tested document pair run three ways, and finishes with a review workflow and the honest limits of the method.

How a diff actually works

A diff algorithm takes two sequences — lines, words, or characters — and finds the changes that turn the first sequence into the second. The classic approach, used by the GNU diff utility for decades and by the JavaScript diff library our tool is built on, finds a longest common subsequence: the largest set of units that appear in both documents in the same order. Everything in the first document but outside that subsequence is reported as removed; everything in the second document but outside it is reported as added; the shared subsequence is unchanged.

That model explains both the power and the blind spots of document comparison:

  • A moved paragraph looks like a deletion plus an addition. The algorithm sees order and content, not intention. If a section moved from page 2 to page 5 unchanged, a diff reports it as removed in one place and added in another.
  • A rewritten sentence can look like a small edit or a total replacement, depending on how many units survive. Change enough words in a line and line mode gives up on it entirely.
  • Formatting is invisible unless it changes the units. In plain text, bolding a word changes nothing. In an HTML file, the same bolding adds tags, which a character or word diff will report — one reason to compare extracted text, not raw markup, when you care about wording.

Our tool accepts pasted text or uploaded .txt, .md, .html, .csv, and .json files, offers ignore-whitespace and ignore-case options, and can export the result as an HTML report you can attach to an email or ticket. Each side is capped at 1,000,000 characters of text — far beyond any policy or contract, but a real cap: a longer input is refused with a message rather than compared partially.

The three modes, on one tested example

To show what mode choice does, we ran one real document pair through the vendored diff library (jsdiff) in all three modes. The pair is a short returns policy, version 1 (254 characters) and version 2 (327 characters). Version 2 makes five human-obvious edits: the return window grows from 30 to 45 days, "with tags attached" is added, the refund time changes from 5 to 7 working days, one whole new sentence about a prepaid label is inserted, and the contact address changes from support@ to returns@. Here is what each mode reported — the actual counts from the run:

Mode Result (measured) What it tells a reviewer
Line 1 line unchanged, 4 lines removed, 5 lines added "Almost everything changed" — technically true, practically useless
Word 3 words removed, 16 words added The exact edits: 30→45, 5→7, support→returns, plus the two insertions
Character 8 characters removed, 81 characters added The same edits, but the email change fragments into pieces like removed s, ppo, t vs added ret, ns

Line mode over-reports. Because every content line in version 2 differs from its counterpart in at least one word, line mode collapsed the entire body into one removed block (4 lines) and one added block (5 lines). Only the heading, "Returns Policy", survived as unchanged. A reviewer reading that report learns that the document changed, and nothing else. Line mode earns its keep on structured text — code, configuration, CSV rows — where one line really is one unit of meaning. For prose, it is the wrong granularity.

Word mode tells the story. The word diff isolated exactly the five intended edits. The removed words were 30, 5, and support; the additions were 45, , with tags attached, 7, the full new sentence "A prepaid return label is included with every order." (10 words), and returns. Sixteen words added against three removed also matches the document growing from 254 to 327 characters. A reviewer can approve or query each change in seconds.

Character mode is precise and noisy at the same time. It found the same insertions, but on the email change it reported micro-fragments — the algorithm matched the shared letters between "support" and "returns" and reported only the non-shared characters. That is mathematically economical and humanly unreadable. Character mode is the right choice for spotting a single changed digit in a long reference number or a swapped character in a code, not for reviewing edited prose.

The lesson generalises: start with word mode for documents, use line mode for structured files, and reserve character mode for hunting one-character differences. The tool's summary counts mean different things in each mode, so always note which mode a report was produced in before comparing counts across reviews.

A review workflow that catches real changes

  1. Get both versions as plain text. Export or copy the text of each version. Comparing extracted text avoids the markup noise described above; if you must compare HTML or Markdown files directly, expect tag and formatting changes to appear alongside wording changes.
  2. Put the older version first. Diff tools label the first input as the source of "removed" text and the second as the source of "added" text. Reversing the pair reverses every label and has confused more than one review meeting.
  3. Run word mode first (for prose) and read the summary counts. If the added/removed counts are far larger than the edit you were told about, something else changed too — that mismatch is the tool doing its most valuable work.
  4. Walk the changes one by one with the next/previous change navigation, accepting or querying each. In our Text Compare tool, the inline view suits a final read-through; the side-by-side view suits spotting a passage that moved.
  5. Check the "unchanged" trap. A passage can be unchanged and still wrong — comparison proves two versions match, not that either is correct. Proofread the final version on its own terms at least once.
  6. Export and file the report. The HTML report is the audit trail: who changed what, and what the reviewer saw. For files that arrive as PDFs, extract the relevant pages first with the method in How to Merge and Split PDF Files, then compare the text.

For structured data, the same discipline applies with different tools: JSON files deserve a structural comparison rather than a text diff, which is the subject of How to Compare Two JSON Files, and CSV files are best compared row by row after cleaning, as in How to Clean and Transform CSV Files.

Common mistakes and troubleshooting

  • Comparing different formats. A .docx original against a pasted plain-text copy will differ in every line ending and smart quote. Convert both sides to the same plain format first.
  • Whitespace floods the report. Re-wrapped paragraphs or trailing spaces make unchanged text look edited. Turn on ignore-whitespace; if the report empties out, the "changes" were formatting only — a useful finding in itself.
  • Case-only changes disappear. With ignore-case enabled, "Support" → "support" is invisible. Leave it off when comparing anything legal, technical, or branded, where capitalisation carries meaning.
  • Huge counts from a tiny edit. You are probably in line or character mode for a prose document. Switch to word mode and re-run before concluding the document was rewritten.
  • A moved section reported twice. That is the deletion-plus-addition pattern described above. Verify the two blocks carry identical text before treating them as new content.

Limits, stated plainly

A text diff compares characters, not meaning. It cannot tell you that "within 30 days" and "within a month" say almost the same thing, or that "shall not" and "shall" say the opposite. It does not compare layout, images, tables as structures, or anything inside a scanned image. And it only ever compares the two versions you give it: if both contain the same error, the diff will faithfully report "unchanged". Use it as the evidence layer of a review, not as the review itself.

Frequently asked questions

Which mode should I use to compare two documents?

Word mode for prose documents such as policies, contracts, and articles — in our tested example it was the only mode that listed the five real edits exactly. Line mode suits code and row-based files; character mode suits hunting a single changed character in a string that must match exactly.

Why does the diff say a whole section was deleted and re-added?

Because it moved, or because enough of its words changed that the algorithm no longer matched it to the original. Read the removed and added blocks side by side: if their text is identical, it was a move; if not, the differences inside the blocks are the real edit.

Can I compare PDF or Word documents directly?

Compare their text. Extract the text from both versions first (for PDFs, split out the pages you need, then copy the text) and run the comparison on the two text versions. Comparing the raw files would compare their internal binary structure, not their wording.

What do the summary counts actually count?

Units of the current mode: lines in line mode, words in word mode, characters in character mode. Our example produced 4 lines removed / 5 added, 3 words removed / 16 added, and 8 characters removed / 81 added — for one and the same edit — which is why a count is meaningless unless the mode is stated with it.

Does comparing documents detect plagiarism or authorship?

No. A diff shows how two specific documents differ; it says nothing about where either text came from. Two documents can be near-identical because one was copied, or because both were generated from the same template — the diff alone cannot distinguish those cases.

References