How to Compare Two Texts and Spot Every Difference
Runs 100% in your browser — nothing on this page is uploaded or stored. Two drafts of one document, two versions of a contract — telling them apart by eye is slow and unreliable. This guide explains how text comparison ("diffing") works, the three comparison levels, how to read the results, and its honest limits.
What "comparing two texts" means
A text diff checker takes two texts and produces a diff: a structured list of what was added, removed, or changed between them. The classic output marks removed lines (often in red, prefixed with −) and added lines (green, +), with unchanged context around them so you can see where each change sits.
The key insight: a diff shows the smallest set of edits that turns one text into the other — usually a tiny fraction of the whole document, which is what makes diffs readable.
The three levels: line, word, and character
Diff tools compare at different granularities, and the right one depends on the job:
- Line-level diff. The classic: compares text line by line. Best for code, config files, logs, and any text where lines are meaningful units. A single changed word marks its whole line as changed — noisy for prose, perfect for code.
- Word-level diff. Compares word by word within lines. Best for prose: contracts, articles, essays. Changing "quick" to "fast" highlights just that word instead of flagging the entire paragraph.
- Character-level diff. The finest grain: highlights individual changed letters. Best for spotting typos, punctuation changes, and single-character edits in identifiers or URLs — the differences your eye skips cleanest.
Good tools combine them: line-level structure with word- or character-level highlighting inside changed lines.
How diff algorithms work (the plain-English version)
Under the hood, most diff tools descend from the Myers diff algorithm (1986), the same algorithm behind the Unix diff command and Git. The idea is elegant: imagine a grid where one text runs along the top and the other down the side. Finding the differences becomes finding the shortest path through that grid — each step right is "delete," each step down is "insert," each diagonal step is "these match."
The algorithm finds the longest common subsequence — the longest content both texts share, in order — and treats everything else as a change. That's why moved text looks odd: the algorithm doesn't understand "moved," only "deleted here, inserted there." A paragraph moved from page 1 to page 5 shows as a deletion plus an addition, even though nothing was rewritten.
You don't need to implement any of this — but knowing that diffs are minimal-edit computations, not understanding, explains every quirk you'll encounter.
Common use cases
- Draft revisions — see exactly what an editor changed, in seconds.
- Contracts — verify a returned redline contains only the agreed changes. (Still have a lawyer read it.)
- Code and configs — line-level diff is the standard way to see what changed between versions.
- Translations — catch dropped paragraphs and untranslated leftovers. It won't judge quality.
- Web monitoring — diff yesterday's page against today's to see exactly what a site changed.
- Copying checks — diffing against a source highlights verbatim overlap. It won't catch paraphrasing.
How to read a diff
Diff output follows conventions worth learning once:
- − / red: content present in the first text but not the second (removed).
- + / green: content present in the second text but not the first (added).
- Unchanged context lines around changes show you where each change happened — don't ignore them when changes look surprising.
- Side-by-side vs unified: side-by-side puts old and new next to each other (easier for prose); unified interleaves them with
−/+markers (standard for code and patches).
When a diff flags huge blocks for a tiny edit, the culprit is usually formatting noise: different line endings, trailing whitespace, or re-wrapped paragraphs. Normalize both texts with our text cleaner first — the "mysterious" diff usually disappears and the real changes stand out.
Honest limits of automated comparison
A diff tool is a diligent idiot: it finds every textual difference and understands none of them. Know the boundaries:
- It can't judge meaning. Replacing "the meeting is on Tuesday" with "the meeting is on Wednesday" and replacing it with "the meeting is cancelled" look equally significant to a diff. Semantic importance is your job.
- Moved text looks like delete + insert. As explained above, reordering shows as removal plus addition. For heavily restructured documents, the diff can be harder to read than the documents.
- Formatting differences drown out content differences. Diffing a Word export against a plain-text version flags every line. Compare like with like, or strip formatting first.
- It won't catch what isn't there. A diff shows changes between two texts; it can't tell you that both are missing a clause that should exist. Absence is invisible.
- Case and whitespace sensitivity. "Hello" vs "hello" is a difference to most diff tools. Decide upfront whether case matters — and if it doesn't, normalize with our case converter before comparing.
A practical workflow
- Normalize both texts. Same line endings, no trailing whitespace, consistent blank lines — the text cleaner does this in one pass.
- Decide if case matters. If not, lowercase both with the case converter.
- Pick your granularity. Line-level for code and configs; word-level for prose; character-level for hunting typos.
- Read the diff, then read around it. Check the unchanged context lines — a change that looks fine in isolation can be wrong in context.
- For long documents, check the counts. Before diving in, run both versions through the word counter: if one draft is 400 words shorter, you know something structural happened before you read a single diff line.
Frequently asked questions
What is the best way to compare two text files?
Normalize both files first (line endings, trailing whitespace), then use a diff tool at the right granularity: line-level for code and configs, word-level for prose. For quick checks, paste both texts into an online compare tool; for versioned work, use Git's built-in diff.
How does a text diff algorithm work?
Most diff tools use the Myers algorithm (1986): they find the longest common subsequence — the longest content both texts share in order — and treat everything else as additions or deletions. The result is the smallest set of edits that converts one text into the other.
Why does my diff show the whole document as changed?
Almost always formatting noise: different line endings (Windows vs Unix), trailing whitespace, or re-wrapped paragraphs. Normalize both texts — strip trailing spaces, unify line breaks, collapse extra blank lines — with a text cleaner and diff again.
Can a diff tool detect plagiarism?
Partially. Diffing a suspect text against a source highlights verbatim copied passages reliably. It won't catch paraphrasing, restructuring, or translated copying — those need semantic comparison, which is a different (and harder) problem.
What is the difference between a diff and a merge?
A diff shows differences between two texts; a merge combines changes from two versions into one. Merging needs a diff plus decisions about conflicting edits — which is why merges can require human judgment when both sides changed the same lines.
Is comparing texts online safe for sensitive documents?
It depends entirely on where the comparison happens. Tools that upload your text to a server expose it; tools that run the diff in your browser with JavaScript never transmit anything. For contracts or unpublished work, prefer the latter — or diff locally with built-in tools.
Prepare your texts for comparison
Clean diffs start with clean input: normalize your text, unify the case, and check the word counts — free, instant, and private in your browser.