Text Compare Online - Diff Two Text Files Side-by-Side
Updated
Compare two text blocks side-by-side. Highlight additions, deletions, and modifications in plain text or code. 100% Private & Free.
Key Features
- ✅ Side-by-side diff
- ✅ Line-by-line comparison
- ✅ Whole-line highlighting
- ✅ Whitespace handling
How to Use
- Paste the original text in the left panel
- Paste the modified text in the right panel
- Differences are highlighted automatically
- Use the summary to see total lines changed
Expert FAQ
- Why does my diff show an entire paragraph as changed when I only edited one word?
This happens with word-wrapped text where line breaks aren't in the same place in both versions — a line-based diff (used by most "diff text" tools and by `diff`/git by default) treats the whole reflowed line as different. This tool actually compares whole lines by position — line i on the left against line i on the right — and highlights the entire line if the two are not byte-identical, so a single-word edit inside a long paragraph will highlight that whole line, including any reflow caused purely by word wrap. - How does it decide which lines "match" when content has been reordered, not just edited?
It does not use the Myers diff algorithm or any edit-script computation — it pairs up lines purely by position (line 1 vs line 1, line 2 vs line 2, and so on), so a single inserted or deleted line will cascade and make every following line show as changed until the two sides re-align by coincidence. For pure reordering with no edits, this generally surfaces as a delete-then-insert pair rather than a "moved" annotation — Myers diff doesn't have a native concept of "moved," only added/removed, which is the same limitation `git diff` has for moved blocks. - Should I use this or JSON Compare / XML Compare for config files?
Use the structured comparers (JSON Compare, XML Compare) whenever both sides parse as valid structured data — they compare by key/value semantically, so reordering object keys or array-formatting differences won't register as false changes. Use plain Text Compare for anything that isn't valid structured data, or when you specifically want to see raw textual/formatting differences (e.g. reviewing a diff of generated YAML or a log file) rather than semantic equivalence. - Does ignoring whitespace also ignore blank lines?
No — "ignore whitespace" normalizes leading/trailing spaces and collapses runs of spaces within a line, but blank lines are still treated as content for line-alignment purposes. If a change is purely the addition/removal of blank lines between paragraphs, it will still show up as a line-count difference.
Technical Details
Text diffing looks simple but has a real algorithmic core: finding the minimum set of insertions and deletions that transforms one text into another (the "shortest edit script" problem) is what the Myers diff algorithm solves, and it's the same algorithm underlying git diff and most IDE diff views. This tool runs that algorithm at two granularities simultaneously — line-level, to align matching regions of the two documents, then character/word-level within each changed line pair, so a one-word edit inside an otherwise identical sentence highlights only that word rather than flagging the whole line as different. The practical limitation worth knowing: Myers diff has no native concept of "this block moved" — a paragraph relocated from the top of a document to the bottom shows up as a deletion at the old position and an insertion at the new one, not as a single "moved" annotation. For prose and code this is usually fine since reviewers can recognize a moved block visually; tools that need true move-detection (some IDE diff views, git's --find-renames option) use additional heuristics on top of the base diff. For comparing structured data (JSON, XML, CSV, YAML) where key order shouldn't matter, use the dedicated JSON Compare / XML Compare / CSV Compare tools instead — they diff by structure and value, not by raw text position, so reformatting alone won't register as a change.