Whether it's two drafts of a contract, two versions of a config file, or a "final_v2" document you're not sure differs from "final_v1" at all, comparing text by eye is slow and error-prone. A diff tool automates this โ but understanding what it's actually comparing helps you read the results correctly instead of being confused by them.
What a "Diff" Actually Compares
Text comparison tools work line by line, not word by word or paragraph by paragraph. The algorithm โ a longest-common-subsequence (LCS) approach โ finds the longest run of lines that appears, in the same order, in both documents. Everything outside that shared sequence gets marked as either removed (only in the first document) or added (only in the second).
This is powerful for catching every literal change, but it means the tool has no concept of "this sentence was rephrased" โ a single edited word inside a long line will show the entire line as changed, since the line itself no longer matches exactly.
How to Compare Two Texts
- Open the Text Diff Checker.
- Paste the original version into the first box and the revised version into the second.
- Turn on "ignore whitespace" if the documents might just differ in indentation or spacing.
- Review the output โ added lines and removed lines are marked separately.
Reading the Results Correctly
A few patterns are worth recognizing:
- A single-word edit shows the whole line as changed. That's expected โ the comparison works at the line level, so any difference within a line marks that entire line.
- A moved paragraph shows as a remove-and-add pair, not a "move." Since the tool compares position in the document, relocating a block of text looks identical to deleting it from one spot and writing new near-identical text in another.
- Reordered list items behave the same way โ moving item 3 above item 1 shows as changes to both positions, even though no wording changed.
Limitations Worth Knowing
Very large documents have a practical ceiling: if the number of lines in one text multiplied by the number of lines in the other exceeds 4,000,000, the comparison won't run, since the underlying computation grows with that product. In practice this only affects extremely long inputs โ most contracts, articles, or code files are well within range โ but if you hit the limit, splitting the comparison into sections works around it.
FAQ
How does a line-by-line diff actually decide what changed? It runs a longest-common-subsequence (LCS) algorithm over the lines of both texts. The algorithm finds the longest sequence of lines that appears, in order, in both versions, then marks every other line as added or removed relative to that shared sequence.
Why does moving one paragraph show as several changed lines? A line-based diff compares position in the document, not meaning โ if a paragraph moves from the top to the bottom, every line around it shifts position too, so the tool reports it as a block of removed lines and a block of added lines rather than a single "moved" change.
Will re-indenting a document show as hundreds of changes? Not if you enable the ignore-whitespace option โ it trims leading and trailing whitespace from each line before comparing, so re-indented lines won't register as changed. Whitespace differences in the middle of a line are still detected either way.
Is there a size limit on how much text I can compare? Yes. If the number of lines in text A multiplied by the number of lines in text B exceeds 4,000,000, the comparison is refused and you're asked for shorter excerpts, since the underlying LCS grid grows with the product of both line counts.