iLoveDevToolRoute first: what are you comparing
"Find what differs between these two texts" — the shape of the input decides the right approach:
| What you're comparing | The right move | Why |
|---|---|---|
| Two config versions, two log excerpts, two code or document versions | Paste straight into a text diff tool (e.g. this site's Text Difference Comparator) | Order is the meaning; line-by-line diff is exactly the right tool |
| Two order-independent lists (dependencies, word lists, file names) | Sort lines on each side first, then compare | Reordering noise buries member differences; after sorting, what remains is pure additions and removals |
| Two JSON documents | Not a text diff — use structural JSON comparison | Key order, whitespace, and escapes create false positives; structural diff reports by field path |
| Changes inside a git working tree | git diff |
The version system already knows who changed what and when; browser tools are for cleaning up after it |
The first two rows are this guide's subject: how to read the views, and how to kill false positives.
How to read a diff view
Results come in two presentations, each with its territory:
- Split view: original on the left, revised on the right, same row numbers aligned, changed rows highlighted. Suits "read both states together" — seeing the before and after of each change clearly; most efficient on a wide screen;
- Unified view: removed lines prefixed
-, added lines prefixed+, read linearly top to bottom. Suits sequential review, narrow screens, and pasting results to others — it mirrorsgit diffanddiff -uoutput, so anyone used to code review parses it instantly.
The common rhythm: locate in split (scan for change clusters with left-right context), then switch to unified to verify details. The addition/removal line counts are the first number to read: they tell you the size of the change surface and whether to read line by line or sample.
Killing the three classes of false positives
Line-by-line diff works by "string-equal lines count as identical", so any semantically meaningless literal difference gets flagged. The three most common:
Whitespace and case noise: indent adjustments, trailing spaces, case changes (true vs True in a config). Turn on ignore-whitespace and ignore-case — but know the cost: they can also mask real changes (whoever edits DEBUG=true into debug=true slips through). Strict first, options second is the safe order.
Line endings (CRLF vs LF): Windows files carry CRLF, Unix carries LF, and to a line diff those are different lines — a file merely opened and saved by a different editor goes fully red. It's the number-one cause of "I changed nothing and everything's flagged"; unify line endings first (the tool's text-adjust menu has a one-click unifier).
Special and invisible characters: zero-width spaces, BOM, decorative symbols — invisible to the eye, fatal to line equality. The ignore-special-characters option strips punctuation and symbol characters from the comparison, which conveniently also removes zero-width noise. The telltale signal: lines that look identical but are flagged.
Normalize before comparing: two high-frequency moves
Sort unordered lists first: comparing two dependency lists or word lists, reordering noise floods the diff. Sort each side lexicographically by line, then compare — every remaining difference is a member-level addition or removal. The criterion in one sentence: is the order itself information? If not, sort.
Normalize reformatted text: when both sides have been through different formatters (indent and wrap styles differ), the diff reports format differences, not content differences. Normalize both with the same rules (line endings, indent policy) first. JSON is special: the format/minify helpers can patch things up in a pinch, but the real answer is structural comparison — that job isn't a text diff's to carry.
Honest limits
- 500,000 characters per side: full logs and data dumps exceed a browser's comfort zone — the command line's
diff -u a.txt b.txthas no such limit, and its output pipes onward; - More than two texts: three-way merge is git territory; a pairwise web tool doesn't do merge semantics;
- History and blame: a text diff answers "what differs", not "when, who, and why" — those live in version control. The web tool's strongest scenario is holding two texts with no repository behind them: two configs pasted from chat, two document versions someone sent, prod vs local output side by side.
Frequently Asked Questions
Why does the diff flag a huge block when I only changed one line?
Three common causes: line-ending mismatch — Windows CRLF and Unix LF are different lines to a line-by-line diff, and a file merely re-saved by another editor goes fully red; unify line endings first. Whitespace noise — indent changes and trailing spaces make lines unequal; turn on ignore-whitespace. Or the text was wholesale reformatted — the diff is then real but useless: normalize both sides with the same rules first, then compare.
How do I compare two lists that are in different orders?
Sort each list by line (lexicographic) with the tool's sort function, then compare — order-independent lists drown the real differences in reordering noise, and after sorting, every remaining difference is a member-level addition or removal. The judgment call is one question: is the order itself information? If yes (a priority list), don't sort; if no (a dependency set), sort.
When should I use split view versus unified view?
Split (side-by-side) suits wide screens and "read the before and after together" work — each change shows both states aligned on the same row. Unified suits sequential line-by-line review, narrow screens, and sharing results — its linear form mirrors git diff output. Switching between the two on the same result is free; locating in split, then verifying in unified, is the common rhythm.
Can a text diff compare two JSON files?
You can paste them in, but you shouldn't: key order, whitespace, and escape spellings produce masses of false positives, and a changed value flags the entire line without pinpointing the field. Compare JSON structurally — it reports adds/removes/changes by JSONPath with key order ignored by default. The text diff's territory is configs, logs, code, and documents — content where the line itself is the unit of meaning.