Diff Checker
Side-by-side line and word-level diffing — with the trade-off between granularity explained honestly.
Paste two versions of a text and this highlights exactly what changed between them — additions, deletions, and unchanged portions, shown side by side. It's the tool for comparing two drafts of an essay, two versions of a contract clause, or an edited paragraph against its original, without manually reading both line by line looking for differences.
Paste two versions above to see exactly what changed.
Line diffing vs. word diffing — the real trade-off
The diff algorithm works by finding the longest common subsequence between the two texts and treating everything else as an addition or deletion — this is the same general family of algorithm used by version-control tools like Git, adapted here for prose rather than code.
Line-level diffing treats each full line as the unit of comparison: if a single word in a long paragraph changed, line diffing shows the entire line as removed and a new entire line as added, even though most of the line's words are identical — because from the algorithm's perspective, a line with even one different word is technically not the same line as before.
Word-level diffing instead treats each word as the unit of comparison, so it can show precisely which word or short phrase within a line changed while marking the surrounding unchanged words as unchanged — much more useful for prose editing, where you usually want to see exactly which words were touched rather than a whole line highlighted for a one-word edit.
The trade-off: word-level diffing is more precise for small edits within a line, but on a heavily rewritten passage (where entire sentences have been restructured rather than lightly edited), it can produce a visually noisier, harder-to-read result than line-level diffing would, since it's trying to find word-level matches across text that's genuinely been substantially rearranged. This tool defaults to word-level diffing for prose but offers a line-level toggle for comparing more structurally different documents, like code or heavily restructured drafts.
Who uses this
- Comparing two drafts of an essay or article to see exactly what an editing pass changed.
- Checking a contract or policy document against a previous version for exact wording changes.
- Verifying a translated or paraphrased passage against the original to confirm only intended changes were made.
Edge cases to know about
- Reordered paragraphs (the same content moved to a different position in the document, not edited) will typically show as one large deletion and one large addition rather than being recognized as "the same content, just moved" — diff algorithms compare in original sequence order and don't detect block-level moves as a distinct operation from this tool's basic word/line diffing.
- Whitespace-only changes (an extra space, a different line-break style) can sometimes show up as a difference even when the visible text reads identically, depending on whether whitespace normalization is turned on — toggle it on if you only care about substantive wording changes and want to ignore formatting-only differences.
- Very long documents with many scattered small changes can produce a diff output that's genuinely hard to scan visually no matter which mode you use — for that case, working in smaller sections (paragraph by paragraph) tends to produce a more readable comparison than one enormous full-document diff.
Related tools
FAQ
- Should I use word-level or line-level diffing?
- Word-level for prose editing, where you want to see exactly which words changed within a mostly-unchanged sentence. Line-level for code, structured documents, or a passage that's been substantially rewritten rather than lightly edited, where word-level diffing would produce a confusing, noisy result trying to match individual words across genuinely different sentences.
- Why does moving a paragraph show as a huge change even though the text didn't change?
- The underlying diff algorithm compares both texts in their given sequence order and doesn't specifically detect "this exact block just moved elsewhere" as its own operation — a moved paragraph is seen as a deletion at its old position and an identical addition at its new position, which is technically correct but can look like a bigger change than it really is.
- Does the diff ignore whitespace differences?
- It can, if you enable whitespace normalization — this ignores differences that are purely extra spaces or different line-break styles, so the diff highlights only substantive wording changes. With normalization off, any whitespace difference (even an invisible one) will show up as a change.
- Can I use this to compare code instead of prose?
- Yes — switch to line-level diffing for code, since code is inherently line-structured (a changed variable name affects one line, not scattered individual words the way a prose edit might), and line-level diffing is the more established convention for reviewing code changes, matching what a version-control diff view shows.
- Is there a limit to how much text I can compare at once?
- There's no hard-coded limit in the tool itself, but because diffing runs entirely in your browser rather than on a server, extremely large documents (tens of thousands of words on each side) can take noticeably longer to compute and render than a normal-length draft — for very large documents, comparing section by section tends to be both faster and easier to read than one giant diff.