How to compare two texts with a diff checker

You got two config files that "should be identical," but one environment boots and the other doesn't. You open them side by side in the editor, scroll up and down, and swear they match. Thirty minutes later you find that someone changed a true to a True on some forgotten line. The human eye is terrible at this, and the more similar the texts, the worse it gets. This is exactly the kind of task a machine solves in milliseconds.

This post is about what a diff checker does under the hood, how to read its output, and when the approach actually pays off. Text comparison and conflict resolution are close cousins — if your problem is merging branches that diverged, it's worth reading how to resolve merge conflicts first, because the tooling is the same family but the context changes everything.

What a diff algorithm actually does

Diff is not "compare character by character and flag the difference." The core problem is more interesting: given text A and text B, what is the shortest sequence of edits (insertions and deletions) that turns A into B? That's the Longest Common Subsequence (LCS) problem, and most tools use a variation of Myers' algorithm, published in 1986 and still the de facto standard in git diff.

Granularity changes the result entirely:

• Line diff: treats each line as an atomic unit. It's Git's default and the most common. Fast and great for code.
• Word diff: splits by word. Useful for prose review, where a line changed in a single word and you don't want the whole line flagged as altered.
• Char diff: maximum granularity. Shows exactly which characters changed inside a word. Good for hunting the invisible character that breaks a parser.

The wrong granularity generates noise. A line diff on a legal contract flags the whole paragraph as "changed" because a comma became a period. A char diff on a code file turns into alphabet soup. Knowing which to use is half the job.

Reading a unified diff without suffering

The unified diff format is what you see in pull requests and in git diff output. It looks scary at first, but it has three pieces:

@@ -12,7 +12,7 @@ def connect(host):
-    timeout = 30
+    timeout = 10
     retries = 3
     return Connection(host, timeout, retries)

The @@ -12,7 +12,7 @@ line is the hunk header. Read it like this: starting at line 12 of the original file, 7 lines; starting at line 12 of the new one, 7 lines. Lines with - were removed, lines with + were added, and lines with no prefix are unchanged context — they're there just so you can orient yourself. Once you understand that -/+ mean "old"/"new" and not "wrong"/"right," the diff stops feeling like a judgment and becomes what it is: a map of changes.

Where this actually solves a problem

Real cases are rarely "two .txt files." They're situations like:

• Config drift: the staging .env and the production one diverged at some point and nobody knows when. A side-by-side diff kills the doubt in seconds.
• Contract review: the version legal sent back has 200 pages and they claim "only one clause changed." Word diff confirms — or refutes — it.
• Log comparison: the request that worked and the one that failed, side by side. The diff highlights the header or payload field that diverges.
• Copy review: marketing rewrote the landing page and wants to know exactly what changed against the approved text.

In all of these, the pattern is the same: two near-identical texts where the difference matters and is hard to spot by eye. To paste two versions and see the difference highlighted instantly, a text diff checker in the browser handles it without opening a terminal or installing anything. It's the kind of task that doesn't justify git, but does justify not trusting your own eyes.

The limits: whitespace and encoding noise

Diff is literal, and that's both its strength and its trap. Trailing whitespace, tab versus space, \r\n versus \n — all of it counts as a difference. You compare two files that render identically and the tool reports 40 changed lines, because one was saved on Windows and the other on Linux.

# normalize line endings before comparing
git diff --ignore-cr-at-eol
git diff --ignore-all-space

Encoding is the silent villain. A UTF-8 file with BOM and another without BOM differ in the first byte, even with identical text. Accented characters in Latin-1 versus UTF-8 also blow up the diff. Before spending time investigating "differences" that don't exist semantically, normalize: same encoding, same line endings, and consider ignoring whitespace if it's not relevant to your case.

Why visual diff beats the eye

The common objection is "I can compare by eye." No, you can't — not reliably, and not with long texts. The human brain is optimized to perceive overall shape, not to detect that character 4,213 changed. That's why typos slip through texts we reread five times.

A visual diff removes that load. It does the deterministic work (finding the shortest edit) and uses color to point your attention exactly where something changed. You stop searching and start judging — which is where your brain actually adds value. The rule of thumb: if the correctness of the comparison matters, don't trust the eye. Paste both sides and let the algorithm point.

Frequently asked questions

What's the difference between line diff, word diff and char diff?

Line diff compares whole line against whole line, char diff compares character by character, and word diff sits in the middle, comparing word by word. Use line diff for code, word diff for prose, and char diff when you need to hunt a specific character inside a word.

Why does the diff report differences when the texts look identical?

Almost always it's whitespace or encoding. Trailing spaces, tab versus space, Windows versus Unix line endings, or a BOM at the start of the file are invisible on screen but count as differences. Normalize encoding and line endings before comparing.

Is a diff checker only useful for code?

No. It works for any text where two versions need comparing: contracts, logs, configs, marketing copy, translations. The algorithm doesn't care about content type, only about the sequence of characters.

Do I need to install anything to compare two texts?

Not necessarily. For versioned files, git diff handles it. For two loose versions you just want to compare once, a browser-based diff checker does the job with no installation.

What to take from here

Diff is a problem solved almost four decades ago, and yet we still insist on doing it by eye and getting it wrong. The right tool turns a frustrating hunt into reading a map: pick the right granularity for the text type, normalize whitespace and encoding before trusting the result, and read the unified diff as a change log, not a verdict. The eye is for judging the change — not for finding it.