What is a text diff?
A text diff (short for "difference") is a comparison between two versions of text that highlights what has been added, removed, or changed. The term comes from the Unix diff command, which has been used by programmers since the 1970s.
When do you need text diff?
- Comparing two versions of a document before and after editing
- Checking what changed between two versions of a contract or agreement
- Comparing code snippets to find bugs
- Verifying that a translation matches the original
- Checking if two similar texts are identical or have subtle differences
- Reviewing content changes made by a collaborator
How to read a diff
In a typical diff view:
- Green highlighted lines — Added (new content in the modified version)
- Red highlighted lines — Removed (content present in original but not in modified)
- Grey/unchanged lines — Same in both versions
Inline vs side-by-side diff
Inline diff shows everything in one column with additions and deletions marked inline. Good for seeing context around changes.
Side-by-side diff shows original on the left and modified on the right, with matching lines aligned. Good for comparing large blocks of text.
How to compare texts online free
- Go to Text Diff Checker
- Paste your original text in the left panel
- Paste the modified text in the right panel
- View highlighted differences instantly
- Switch between inline and side-by-side view
- Use "Ignore whitespace" option to focus on content changes
Practical uses
Contract review
Paste the original contract on the left and the revised version on the right. Every change is immediately visible — no need to read the entire document.
Content editing
Compare your draft with a colleague's edits to see exactly what they changed.
Code comparison
While dedicated tools like GitHub exist for code, a text diff is useful for quick comparisons without setting up version control.
Why diffs sometimes look nonsensical
A diff algorithm finds the shortest set of changes converting one text into another. That is not always the set of changes a human would describe.
Move one paragraph from the top of a document to the bottom, and most diff tools show it as a large deletion plus a large insertion rather than "moved". The text is identical, but the algorithm operates on line positions, not intent.
Similarly, changing a single word in a long line marks the entire line changed if the diff is line-based. This is why word-level and character-level diffs exist — they are slower but far more readable for prose, where a paragraph is often one long line.
Rule of thumb: line diffs for code, word diffs for prose. Using a line diff on a document where paragraphs are unwrapped produces a wall of red and green that communicates nothing.
Whitespace noise
The most common reason a diff is unreadable is invisible changes.
An editor that converts tabs to spaces, or changes line endings from CRLF to LF, marks every line as modified while nothing visible changed. The same happens when a tool strips trailing whitespace on save.
Most diff tools offer "ignore whitespace" for exactly this. Turn it on when a diff shows far more changes than you made — it usually collapses to the two lines you actually edited.
Line endings deserve their own mention: files edited on both Windows and macOS in the same project routinely produce whole-file diffs. Configuring the editor or version control to normalise them prevents it.
Reading a unified diff
The format is worth being able to read directly, since it appears in code review, patches, and version control output:
@@ -12,7 +12,8 @@
unchanged context line
-removed line
+added line
+another added line
unchanged context line
The @@ header means: from the original file, 7 lines starting at line 12; in the new file, 8 lines starting at line 12. Lines with a leading space are context, shown to help locate the change. A single space before a line is significant — that is what distinguishes context from content.
Diffing structured data
For JSON, XML, or CSV, a plain text diff is often misleading because formatting differences swamp real ones. Reordering keys in a JSON object changes nothing semantically but produces a large text diff.
The fix is to normalise before comparing: pretty-print both files with consistent indentation and sort keys where order is not meaningful. For CSV, sorting rows by a stable key first turns "everything changed" into the handful of genuinely different rows.
Frequently asked questions
What is a three-way merge?
Comparing two versions against their common ancestor rather than against each other. This lets a tool tell "you added this line" apart from "they deleted this line" — the distinction that makes automatic merging possible.
Why do some tools show moved blocks and others do not?
Move detection is a separate, more expensive analysis layered on top of the diff. Some tools implement it; the standard algorithm does not.
Can I diff two Word documents here?
Not directly — .docx is a compressed archive, not text. Paste the text content of both instead, or export to plain text first.
Is there a size limit?
The practical limit is browser memory, since comparison runs locally. Very large files may be slow because diff algorithms scale worse than linearly with input size.
Is my text uploaded?
No. Comparison happens entirely in your browser, which matters for contract review and unreleased drafts — the two most common reasons people reach for a diff tool.