Staging works and production doesn’t. The two config files look identical, and you’ve read them side by side three times. A diff will find the one line that’s different in about a second.
What is a diff
A diff (short for difference) compares two pieces of text and shows you exactly what changed. It’s the thing behind Git and every code review tool. It’s just as handy for documents, config files, SQL queries or the notes you rewrote last week.
The idea goes back to the Unix diff command from the early 1970s. It compares two files line by line and prints the lines that differ. Modern tools add colour and line numbers, but the core idea hasn’t changed in fifty years.
Reading the unified diff format
The format you’ll see most often is the unified diff, which Git uses. Say someone changed the port and turned on debug mode:
--- original.txt
+++ modified.txt
@@ -1,5 +1,5 @@
const config = {
- port: 3000,
+ port: 8080,
host: "localhost",
- debug: false,
+ debug: true,
};- Lines starting with
-exist only in the original text. - Lines starting with
+exist only in the modified text. - Lines starting with a space are unchanged. They’re there for context, so you can tell where you are in the file.
- The
@@ -1,5 +1,5 @@line is a hunk header. It means “this chunk covers 5 lines starting at line 1, in both files”.
Notice there’s no “modified” marker. A changed line shows up as the old line removed and the new line added.
When comparing text saves you
Code review
Pull requests already show you a diff. Outside Git, it’s useful when a teammate pastes “the fixed version” of a function into Slack and you want to know what they actually fixed.
Configuration files
Compare the production and staging versions of an Nginx config, a .env file or a Kubernetes manifest. Different upstreams, timeouts and feature flags jump out straight away.
Document versions
Writers, editors and lawyers compare drafts to see which sentences were added or removed. In a contract, one quietly changed line can matter a lot.
SQL queries
You rewrote a query to make it faster. A diff of the before and after confirms you didn’t also change a WHERE clause, a join or the selected columns along the way.
How to use the text diff tool
- Open the text diff tool and paste the old version into Original text.
- Paste the new version into Modified text.
- Select Compare. You get one column with the line number from each side and a
+or-marker. Added lines are green and removed lines are red. - Above the result you’ll see how many lines were added, removed and unchanged. Select Copy to copy the diff as plain text with
+and-prefixes.
The comparison is exact and works on whole lines. A line that differs only by a trailing space or a capital letter counts as changed. Everything runs in your browser, so nothing you paste is uploaded.
Tips for cleaner comparisons
- Normalise whitespace if you only care about content. Otherwise an editor that reindented the file makes every line look changed.
- Use the same line endings. Windows ends lines with CRLF and Linux and macOS use LF. Compare one of each and every line can show up as different, even though they look the same.
- Sort unordered content such as lists or environment variables first, so a different order doesn’t look like a change.
- Break up long lines. The diff works on whole lines, so one typo fix in a long paragraph marks the entire paragraph as changed. One sentence per line makes the real change easy to find.
- Ignore generated noise such as timestamps or build hashes that change on every version.
How diff algorithms work
Diff tools look for the longest common subsequence (LCS) of lines: the biggest set of lines that appear in both texts in the same order. Anything outside that set is reported as removed or added.
The text diff tool builds a plain LCS table, which is fine for anything you’d paste into a browser. Git uses the Myers algorithm, which finds a minimal diff in O(ND) time. N is the combined length of both files and D is the number of differences, so Git stays fast on huge files with only a few changes.