How to Compare Two Texts or Files and See Exactly What Changed
You have two versions of something — a config file before and after a deploy, two drafts of a contract, the API response from yesterday and today, a function someone edited — and you need to know precisely what changed. Reading both side by side and hunting for the difference is slow and error-prone. A diff tool does it in a second and shows you exactly the lines and words that moved. Here’s how diffing works and how to get a clean, meaningful comparison.
What a diff actually does
A diff tool aligns two pieces of text and reports the minimal set of changes that turns one into the other. Conceptually, it finds the longest common subsequence — the largest run of lines (or words, or characters) that appear in the same order in both versions — and treats that as unchanged. Whatever’s left over is marked as removed from the old version or added in the new one.
This is why a diff often represents an edited line as a removed line plus an added line, rather than an in-place tweak: at the line level, “modified” is just “old line gone, new line arrived.” Understanding that makes diffs much easier to read.
Choosing the right granularity
Diffs can compare at different levels, and picking the right one is the difference between clarity and noise:
- Line diff — compares whole lines. Ideal for code, config files, CSVs, and logs, where structure is line-based.
- Word diff — compares word by word. Ideal for prose: it shows exactly which words changed inside an otherwise-identical sentence, instead of flagging the whole paragraph.
- Character diff — compares character by character. Best for catching a single typo, a changed digit in an amount, or a flipped letter in a slug.
The Diff Checker lets you paste both versions and see the additions and removals highlighted. For a paragraph that was lightly reworded, a word diff tells the story; for a refactored function, a line diff does.
Reading a diff
The conventions are simple once you know them: removed content (present in the old version, gone in the new) is marked one way — often a red highlight or a leading - — and added content is marked another, often green or a leading +. Unchanged lines are shown as context so you can see where in the file the change sits. Scan for the marked regions; everything else is unchanged.
Normalize before you compare
The most common frustration with diffing is a result full of “changes” when the content looks the same. The culprit is invisible formatting:
- Line endings — Windows (CRLF) versus Unix (LF) line endings make every line look different.
- Whitespace — trailing spaces, tabs versus spaces, inconsistent indentation.
- Structure — for JSON or other structured data, a different key order or indentation is textually different but semantically identical.
Format first, then diff
Before comparing two JSON payloads or config blobs, run each through a formatter so they share the same indentation and (where possible) key order. The JSON Formatter does this; diffing the pretty-printed versions surfaces the real change instead of a wall of formatting noise.
Where diffing helps
A diff isn’t just for code review. It’s the fastest way to:
- Spot config drift — what’s different between a working environment and a broken one.
- Review contract or document changes — exactly which clauses or numbers were edited between drafts.
- Compare API responses — what a payload gained or lost between two calls.
- Check an AI or auto-formatted rewrite — confirm a tool only changed what you expected.
Keep sensitive comparisons local
Configs often contain hostnames and credentials; contracts and documents contain personal and commercial details. Pasting them into a server-side comparison tool uploads that content to someone else’s infrastructure. A diff that runs in your browser keeps both versions on your device — you can confirm it the usual way, by checking the Network tab while you compare. For text manipulation generally — case conversion, counting, slugs, and the rest — see the string and text processing toolkit.
The takeaway
To compare two texts well: pick the right granularity (line for code, word for prose, character for a single typo), normalize formatting first so the diff shows the real change rather than whitespace noise, and keep sensitive files on your own machine with a client-side tool. Done that way, a diff turns “something changed somewhere” into “here is exactly what changed,” in one glance.