Diff Checker: How It Works
A diff checker compares two texts and shows exactly what changed. Reading a diff well is a skill worth having: it is how code review works, how contract redlines are checked, and the fastest way to answer 'what is different about this version?'
How a diff is computed
Most tools solve the longest common subsequence problem: find the largest set of lines appearing in both texts in the same order, then mark everything else as added or removed. There is no concept of 'moved' or 'edited' — a changed line is represented as one deletion plus one addition, which is why a small edit to a long paragraph can look like a wholesale rewrite.
| Marker | Meaning |
|---|---|
- / red | Present in the original, absent in the new version |
+ / green | Present in the new version only |
| unchanged | Context, shown to locate the change |
Granularity changes what you see
| Level | Best for | Weakness |
|---|---|---|
| Line | Code, configuration, structured data | Prose reflows into one enormous change |
| Word | Documents, contracts, articles | Noisy on code |
| Character | Short strings, IDs, hashes | Unreadable on anything long |
The most common frustration — 'it says the whole paragraph changed when I altered one word' — is a granularity mismatch. Prose written as one long line per paragraph produces a line diff that is technically correct and useless. Word-level comparison fixes it.
Whitespace
Invisible differences are the ones that waste time: trailing spaces, tabs versus spaces, and line endings. Windows uses carriage return plus line feed (\r\n) while Unix, Linux and macOS use line feed alone (\n). A file that has passed through both systems can show as entirely changed while looking identical, because every single line differs by one invisible character.
Most tools offer an option to ignore whitespace. Turn it on when comparing content and off when comparing anything where whitespace is significant — Python, YAML, Makefiles.
Reading a diff well
- Check the scale first. Ten changed lines is a review; a thousand needs a conversation about what happened.
- Separate formatting from substance. A reformat mixed with a logic change hides the logic change. Ask for them as separate commits.
- Look at deletions as carefully as additions. Removed error handling is invisible if you only read the green.
- Read the context lines. A change that looks fine in isolation may be wrong for the block it sits in.
Practical uses beyond code
- Contract redlines — comparing a returned draft against what you sent, which catches quiet edits.
- Configuration drift — comparing a working environment against a broken one.
- Editorial review — seeing exactly what an editor changed.
- Data validation — comparing an export before and after a migration.
This comparison runs entirely in your browser, which matters for the contract and configuration cases — both routinely contain material that should not be pasted into a server-side tool.