A WP Adminify customer once sent me two exports of his plugin settings — "before the update, everything worked; after, the admin menu is broken. Nothing else changed." Two JSON blobs, each about 340 lines. I read them side by side, twice, and confidently agreed with him: identical. Nothing changed. Must be our bug.
It wasn't. When I finally stopped trusting my eyes and diffed the two files, there it was on line 217: a menu role key had gone from "administrator" to "administrator " — with a trailing space. One invisible character. I had personally read past it twice, because human eyes don't compare strings; they pattern-match shapes, and administrator and administrator have the same shape.
That support ticket permanently changed my rule: if two texts are longer than about ten lines, I don't compare them by reading. Ever. A diff algorithm has no pattern-matching shortcuts to fool — it compares every character and reports exactly what differs. The Text Diff tool on toolz.dev does this in your browser, which means customer configs, contracts, and unreleased code never leave your machine. Here's how diffing actually works and how to use it well.
TL;DR: Never visually compare texts longer than a few lines — eyes miss trailing spaces, swapped digits, and single-word edits. Paste both versions into the Text Diff tool: green = added, red = removed, computed by the same Myers algorithm family that powers
git diff. Use line mode for code and configs, word mode for prose and contracts. For structured data, the JSON Diff compares by meaning instead of by text. Everything runs client-side.
How Does a Diff Algorithm Actually Work?
The core idea: find the longest common subsequence (LCS) of the two texts — the longest sequence of lines (or words, or characters) that appears in both, in the same order. Everything in the LCS is "unchanged." Whatever's left in version A is a deletion; whatever's left in version B is an addition. A "modified" line is just a deletion and an addition that happen to sit next to each other.
The standard way to compute this efficiently comes from Eugene Myers' 1986 paper, "An O(ND) Difference Algorithm and Its Variations". The elegant part is what the complexity bound says: N is the input size, but D is the number of differences. Two nearly-identical texts diff almost instantly no matter how long they are, because the algorithm's work scales with how different they are, not just how big. That's why diffing two 300-line configs that differ by one line feels instant — the algorithm is doing almost nothing, which is exactly the situation where your eyes are doing the most work and failing.
This same algorithm family is the default engine in git diff, GNU diff, and most comparison tools you've ever used. (Git also offers patience and histogram variants that sometimes produce more human-readable groupings of the same changes — the set of changes is the same, the presentation differs.)
One important non-obvious property: a diff is not always unique. If you add a blank line between two existing blank lines, "which" blank line is new is genuinely ambiguous, and different tools may highlight different ones. Both answers are correct.
Line, Word, or Character Diff — Which Mode When?
The granularity you compare at changes what the output is good for. Getting this wrong is the main reason people find diff output "noisy."
| Line-level | Word-level | Character-level | |
|---|---|---|---|
| Compares | Whole lines as atoms | Individual words | Individual characters |
| A one-word edit shows as | Entire line removed + re-added | Just that word | Just the changed letters |
| Best for | Code, configs, CSV rows | Prose, contracts, docs | Typos, hashes, encoded strings |
| Weakness | Long-paragraph edits: you still hunt within the line | Noisy across reflowed/rewrapped text | Unreadable for large edits |
| Classic user | git diff |
Legal blackline / editorial review | "These two API keys look identical" |
Concrete example. Original: The quick brown fox jumps over the lazy dog. Modified: The quick red fox leaps over the lazy cat.
- Line mode flags the whole sentence as changed — accurate, unhelpful.
- Word mode highlights exactly
brown→red,jumps→leaps,dog→cat. - Character mode is overkill here, but it's the only mode that would catch
admlnistratorvsadministrator.
Rule of thumb: structured text (one meaningful statement per line) wants line mode; flowing text wants word mode; character mode is a magnifying glass you pull out when the other two say "changed" and you can't see why. My trailing-space bug is the canonical character-mode case.
When Is a Standalone Diff Tool Better Than Git?
Git's diff is excellent for things that live in the same repository. A surprising amount of comparison work doesn't:
Support tickets. The scenario from my intro — two settings exports from a customer. They're not in any repo. Paste both into the Text Diff tool and the answer appears in seconds instead of two failed read-throughs.
Config drift. Staging nginx config vs production nginx config. Current .env vs the backup from before things broke. git diff can't see files on two different servers; copy-paste can.
Formatter verification. You ran Prettier (or PHPCS, or Black) across a file and want confidence it changed formatting only. Diff the before and after: if you see anything other than whitespace, quotes, and semicolons, the formatter touched logic and you want to know now.
Two API responses. Staging returns one JSON body, production returns another, and the frontend only breaks in staging. Diff the responses. (For JSON specifically, prefer the JSON Diff — it compares parsed structure, so key order and whitespace don't create false positives. Run both payloads through the JSON Formatter first if you want a readable text diff instead.)
Documents and contracts. A vendor returns "the same contract with minor updates." Word-mode diff is how you discover the payment terms went from Net 30 to Net 15 in a 40-page document. Editors and lawyers have known this forever — they call it a blackline or redline.
Translation and localization files. Comparing two versions of a .po file to see which strings actually changed before sending it back to translators — a real WP Adminify workflow that saves paying to re-translate 400 unchanged strings.
The common thread: the moment both versions exist as text you can select, a diff tool answers "what changed?" mechanically. And because the toolz.dev tool is client-side, pasting a customer's config or an unsigned contract doesn't transmit it anywhere — the same argument as the rest of the privacy-first toolbox.
How Do You Read Diff Output Without Fooling Yourself?
The color convention is universal: red is the old version's exclusive content (removed), green is the new version's (added), unchanged text renders plain for context. A changed line appears as a red line followed by its green replacement.
Three habits that make diff review actually reliable:
Put the versions in the right slots. Old/original on the left (or first field), new/modified on the right. Swap them and every addition reads as a deletion — I've watched people debug the wrong direction for ten minutes because of this. If the output looks backwards, it probably is.
Decide what noise is before you start. Comparing reformatted code? Whitespace changes are noise — normalize or ignore them. Comparing YAML configs? Whitespace is meaning — indentation is structure in YAML, so validate both sides in the YAML Validator and treat every space as signal. Same tool, opposite policies, and choosing wrong either buries the real change in noise or hides it.
Read every hunk, not just the first one. The customer's trailing space was change #1 of 1. But when a diff shows four changes and the first one explains your symptom, the temptation to stop reading is strong — and change #3 is sometimes the one that bites you next week. The diff already did the hard part; don't re-introduce human sampling error at the last step.
What Can't a Text Diff Tell You?
Worth being honest about the limits:
- Moved blocks read as delete + add. Cut a function from the top of a file and paste it at the bottom: the diff reports it removed and added, not moved. Some specialized tools detect moves; plain LCS doesn't.
- It compares text, not meaning.
0.1 + 0.2and0.3diff as different (they are) but also behave differently in floating point — and conversely,"key": 1vs"key": 1.0may be textually different but semantically identical in your language. Structured comparison (like the JSON Diff) closes part of this gap for data formats. - Binary content is out of scope. Images, PDFs as bytes, executables — text diff needs text. Extract the text first, or use format-specific tools.
- Case and encoding are compared literally.
README≠readme, and a UTF-8 curly quote ≠ an ASCII straight quote even though they look identical in most fonts. (Another shape-pattern trap for eyes, another win for the algorithm.) Pre-normalize with the Case Converter if case shouldn't matter for your comparison.
Frequently Asked Questions
Can I compare files, or only pasted text?
The Text Diff tool works on pasted text: open each file in any editor, copy, paste both sides. That makes it format-agnostic — anything that's readable text (code, config, CSV, SQL, prose) can be compared, regardless of extension.
Is there a size limit for comparison?
The practical limit is your device's memory, since processing is in-browser. Files with a few thousand lines compare instantly; the Myers algorithm's cost scales with the number of differences, so even large but similar texts stay fast. Hundreds of thousands of lines with massive differences may take a few seconds.
Which diff mode should I use for code?
Line mode. Code is naturally one-statement-per-line, so line-level output maps cleanly onto how you think about the change. Switch to word or character mode only when a line is flagged as changed and you can't spot the difference within it — that's usually whitespace, quotes, or a single character.
Which mode is best for contracts and prose?
Word mode. Prose changes are usually word substitutions and inserted clauses inside long paragraphs; line mode would flag entire paragraphs and leave you hunting. Word-level highlighting shows exactly which words changed — the same approach as a legal blackline.
Does the diff modify or store my text?
No. Highlighting exists only in the rendered output; your input text is unchanged, and because the tool runs entirely client-side, neither version is transmitted or stored anywhere. Close the tab and the texts are gone.
Why does the diff highlight a line that looks identical?
Almost always invisible characters: trailing spaces, tabs vs spaces, Windows \r\n vs Unix \n line endings, non-breaking spaces, or Unicode lookalikes (curly vs straight quotes). This is precisely the class of change human eyes cannot see and diff algorithms always catch — my trailing-space support ticket was one of these.
Can it detect moved text?
Not as a move. Standard LCS-based diffing reports a moved block as deleted from the old location and added at the new one. If you suspect a move, search the "added" text in the original — an exact hit elsewhere in the file confirms it.
How is JSON Diff different from Text Diff?
Text diff compares characters; JSON Diff parses both documents and compares structure. Reordered keys, changed indentation, and trailing commas produce zero structural differences, so you see only changes in actual values and keys. Use it whenever both sides are valid JSON; fall back to text diff when they aren't.
How do I ignore whitespace or case when comparing text?
Decide first whether whitespace is noise or signal: in reformatted code it is noise, but in YAML or Python indentation it is structure. When it is noise, normalize both sides before diffing — collapse repeated spaces, strip trailing whitespace, and make line endings consistent — so only real changes remain. To ignore case, lowercase both texts before comparing, since the diff treats README and readme as different by default.
What algorithm does git diff use?
By default git diff uses a variant of the Myers algorithm, the same longest-common-subsequence approach from Eugene Myers' 1986 paper that most diff tools share. Git also offers patience and histogram variants that can group changes more readably, but they report the same set of differences — only the presentation changes. This tool uses the same Myers algorithm family.
