How to Compare Two Texts Online: Reading a Diff, Ignoring Noise and Comparing Files

Comparing two texts, step by step

Paste the original on the left and the changed version on the right. Order matters: removals are shown relative to the left side and additions relative to the right, so swapping them turns every red line green.

Read the summary first. It shows how many lines were added and removed. A handful of changes in a long document is what you expect; hundreds of changes in two texts you believed were nearly identical point to a formatting difference such as line endings, indentation or reflowed paragraphs, not a content change.

Then walk the changed blocks in order. Most tools collapse unchanged regions and show a few lines of context around each change, which is usually all you need to understand it.

For confidential text, use a checker that runs in the browser. Contracts, configuration with secrets and customer data should not be pasted into a service that uploads the input, and a local comparison is just as fast.

How a diff is computed

Almost every diff tool solves the same problem: find the longest common subsequence of the two inputs, the items that appear in both in the same order, and report everything else as a deletion or insertion. Eugene Myers' 1986 paper, "An O(ND) Difference Algorithm and Its Variations", gave the fast method still used by GNU diff and as Git's default. Its running time grows with the size of the input times the number of differences, so near-identical texts compare very quickly.

left : the quick brown fox
right: the quick red fox

common subsequence: the quick _ fox
diff:  the quick [-brown-]{+red+} fox

The minimal diff is not always the most readable one. When the same line, such as a closing brace or a blank line, appears many times, the algorithm may align the wrong copies and produce a confusing block. Git offers --patience and --histogram, which anchor on lines that occur only once and usually give a diff closer to what a human would write.

Line, word or character diff

Line diffs treat each line as one unit. A single changed character marks the whole line as removed and re-added. That is right for code and configuration, where lines are meaningful units.

Word diffs split on whitespace and are better for prose, where one edited word in a long paragraph would otherwise hide in a two-line change. Character diffs show exactly which characters differ, which is what you need for IDs, hashes, API keys and URLs.

line diff:
- The invoice is due on 12 March 2026.
+ The invoice is due on 21 March 2026.

word diff:
  The invoice is due on [-12-]{+21+} March 2026.

character diff:
  The invoice is due on [-1-]2{+1+} March 2026.

Paragraphs pasted from a word processor are often one very long line each. A line diff then marks the whole paragraph as changed. Switch to word diff instead of hunting through it.

Removing noise before you compare

Most "everything is different" results come from differences that are invisible on screen.

Line endings: Windows uses CRLF (\r\n), Linux and macOS use LF (\n). A file saved on each will differ on every line. Whitespace: trailing spaces, tabs against spaces, and re-indentation all register as changes. Encoding and invisible characters: a UTF-8 byte-order mark at the start, non-breaking spaces from web pages or word processors, and zero-width spaces all look identical to ordinary text. Smart quotes: ’ and ' are different characters, and word processors substitute them automatically.

Use the checker's options to ignore whitespace or case when those differences do not matter to you. For lists whose order does not matter, sort both sides first, for example with a sort lines tool, so the diff shows only real additions and removals. For structured data, normalise first. Diff two JSON documents after formatting both with sorted keys, and two lists after sorting them, so that reordering is not reported as a change.

# JSON: same data, different key order and spacing
jq -S . a.json > a.norm.json
jq -S . b.json > b.norm.json

# Lists: compare as sets
sort -u a.txt > a.sorted; sort -u b.txt > b.sorted
comm -3 a.sorted b.sorted     # lines unique to either side

Reading unified diff output

Command-line tools, Git and code review systems use the unified format. Once you can read it, you can read any patch.

--- a/config.yml          <- the left (original) file
+++ b/config.yml          <- the right (changed) file
@@ -12,7 +12,7 @@ server:   <- hunk: 7 lines from line 12 on each side
   host: 0.0.0.0
   port: 8080
-  timeout: 30            <- only in the original
+  timeout: 60            <- only in the new version
   workers: 4

Lines starting with a space are unchanged context. The @@ header gives the starting line and line count for each side. That is how a patch tool finds where to apply the change, even if the surrounding file has moved a little.

Comparing on the command line

For files already on disk, or for comparisons inside scripts, the built-in tools are enough.

# Linux / macOS
diff -u old.txt new.txt                 # unified diff
diff -u -w old.txt new.txt              # ignore all whitespace
diff --strip-trailing-cr a.txt b.txt    # ignore CRLF vs LF (GNU diff)

# Git works on any two files, even outside a repository
git diff --no-index old.txt new.txt
git diff --no-index --word-diff old.txt new.txt
git diff --no-index --ignore-cr-at-eol a.txt b.txt

# Windows cmd
fc /n old.txt new.txt

# PowerShell: lines unique to each side
Compare-Object (Get-Content old.txt) (Get-Content new.txt)

Compare-Object compares lines as collections, not as ordered sequences, so it tells you which lines exist on only one side, not where they moved. It is useful for lists and poor for documents.

Practical uses

Reviewing edits to a contract or policy when the other side did not track changes. Checking which settings differ between the staging and production configuration. Comparing an API response before and after a deploy. Finding what a colleague changed in a SQL query or a shell script. Confirming that two copies of a document really are identical before you delete one.

For the last case, a checksum is faster than reading a diff. Two files with the same SHA-256 hash are identical; different hashes tell you to run a diff and find out where.

Sources and further reading

Eugene W. Myers, "An O(ND) Difference Algorithm and Its Variations", Algorithmica 1(2), 1986. The GNU diffutils manual documents the unified format and the -w and --strip-trailing-cr options. The Git documentation for git diff covers --no-index, --word-diff, --patience and --histogram.

Frequently asked questions

How do I compare two texts for differences?

Paste the original into the left pane of a diff checker and the changed version into the right. The tool highlights removed text on the left and added text on the right. Use a word diff for prose and a line diff for code.

Why does the diff show every line as changed?

Usually an invisible difference: Windows CRLF versus Unix LF line endings, changed indentation, trailing spaces, or a byte-order mark. Turn on "ignore whitespace", or normalise line endings, and compare again.

How can I compare two files online?

Open or paste both files into a diff checker. Prefer one that runs in the browser so the contents are not uploaded, especially for configuration, contracts or anything containing personal data.

What algorithm do diff tools use?

Most use Myers' O(ND) algorithm, which finds a shortest edit script based on the longest common subsequence. Git also offers patience and histogram diffs, which often produce more readable results for code.

How do I compare two texts ignoring order?

Sort both inputs first, then diff them, or use `comm` on sorted files to list lines unique to each side. For JSON, reformat both with sorted keys, for example with `jq -S`, before comparing.

Can I compare two texts in Word or Google Docs?

Yes. Word has Review › Compare, and Google Docs has Tools › Compare documents. Both work well for formatted documents; a plain-text diff checker is faster for code, data and configuration.