PipFoxy
PipFoxy guide

How to compare two text documents

Text comparison turns two versions into additions, removals and unchanged context. The display can make edits easier to review, but it does not decide whether a change is correct. Good comparison starts with the right source versions and carefully chosen normalisation options.

Updated 7 minute read

Start with clearly identified versions

Put the earlier or baseline document in the original field and the newer candidate in the revised field. This direction determines which text is labelled removed and which is labelled added. Reversing the inputs does not change the underlying difference, but it reverses the story the output tells.

Remove page headers, timestamps or export artefacts only when they are outside the content being reviewed. Keep untouched copies so cleanup cannot accidentally become part of the approved revision.

  • Record where each version came from.
  • Confirm neither document was truncated during copying.
  • Use plain text when layout changes are not part of the review.

Line and word comparisons answer different questions

A line-level comparison is ideal for lists, configuration-like text and paragraphs that remain in roughly the same order. It shows structural additions and removals clearly. A word-level comparison can then highlight smaller edits inside a changed line.

No automatic diff understands intent. Moving a paragraph may appear as one removal and one addition, while rewriting a sentence heavily may look like two unrelated blocks. Read the surrounding unchanged context before interpreting counts.

Ignore options deliberately

Ignoring whitespace can suppress changes caused only by extra spaces or line endings. Ignoring case can treat Tool and tool as equal. These options are useful for noisy exports, but they can hide meaningful edits in source code, passwords, identifiers and carefully formatted plain text.

Run a normal comparison first. If formatting noise overwhelms the result, enable one ignore option at a time and state that choice in any exported summary. A clean-looking diff is not valuable if it concealed a material change.

  • Case can be meaningful in names, identifiers and code.
  • Whitespace can be meaningful in tables, poetry and indentation-sensitive formats.
  • Normalised comparisons should not overwrite the original documents.

Read a diff without relying on colour

Accessible comparison output labels additions and removals with text or symbols as well as colour. In a unified view, changes appear in one sequence with shared context. In a side-by-side view, aligned panels make local edits easier to scan but can require horizontal space.

Use keyboard navigation and a screen reader's landmarks or headings when reviewing a long comparison. Counts of added, removed and changed lines are useful for orientation, not as evidence that a revision is safe.

Review changes by risk

First inspect names, dates, quantities, obligations, negations and links because small edits there can carry large consequences. Then review additions for unsupported claims and removals for lost qualifications. Finally, read the revised document continuously; a sentence can be locally accurate but awkward in its new context.

For legal, financial, medical, security or contractual material, a browser diff is an aid rather than professional review. Export a summary for discussion, but retain both source documents and obtain the appropriate expert sign-off.

  • Check changed numbers and units character by character.
  • Look for removed words such as not, only and except.
  • Open revised links rather than trusting similar-looking text.
  • Read the final document after finishing the diff review.

Explore another practical PipFoxy guide.

View all guides