What a text diff actually shows you
Instead of reading two documents side by side and hoping you spot every edit, a diff tool does the alignment mathematically. It finds the longest sequence of words, lines, or characters that both texts have in common, in the same order, and treats everything outside that shared backbone as a change. That's what separates a real diff from a simple "these two strings aren't equal" check — it tells you specifically what changed and where, not just that something did.
A browser-based comparison tool that implements this with plain JavaScript can run the whole calculation client-side: paste the old text into Text A and the new one into Text B (or upload a .txt, .md, or code file for each), and the comparison updates as you type. Nothing is sent to a server, which matters if you're comparing a contract draft, source code, or anything else you'd rather not upload anywhere.
Word, line, or character mode — which one to pick
The three modes don't just change how the diff looks — they change what counts as "one unit" for the alignment algorithm. In line mode, an entire line is either matched, added, or removed as a block, which is exactly how source control diffs work and why it's the natural choice for code, config files, and logs. Word mode breaks a sentence into individual words, so a single swapped adjective shows up as one small change instead of the whole line turning red. Character mode goes finer still, catching a single flipped letter that word mode would otherwise report as "one word changed."
| Mode | Compares | Best for |
|---|---|---|
| Line | Whole lines | Source code, config files, logs, lists |
| Word | Individual words | Articles, emails, translations, contracts |
| Character | Individual characters | Typo fixes, short strings, IDs or keys |
A tool with a side-by-side and an inline view lets you pair either mode with a layout: side-by-side puts Text A and Text B in two columns (removals highlighted in the left column, additions in the right), which mirrors how most people already read code reviews; inline weaves both into one flowing block, which tends to read more naturally for prose. Turning on "Ignore case," "Ignore whitespace," or "Ignore punctuation" beforehand can also strip out cosmetic differences — like re-indented code or a re-typed sentence with the same words — so the diff only flags changes that actually matter.
How the similarity ratio is calculated
The ratio is essentially a measure of overlap: how much of the combined content between the two versions is shared, versus how much was changed. Because it's based on matched units rather than raw character counts, the mode you pick changes the number — line mode measures structural overlap between files, while character mode gives the most granular reading of textual similarity.
Take a small, illustrative example: comparing "red fast car" (Text A) to "blue fast car" (Text B) in word mode. Two words match ("fast" and "car"), one word was removed ("red"), and one was added ("blue"). Plugging into the formula: (2×2) / (2×2 + 1 + 1) × 100 ≈ 66.7%. This is a made-up example to illustrate the math, not a benchmark from real documents — your own similarity score will depend entirely on the two texts you paste in.
| Word | In A? | In B? | Status |
|---|---|---|---|
| red | yes | — | removed |
| blue | — | yes | added |
| fast | yes | yes | matched |
| car | yes | yes | matched |
Reading a colored diff correctly
Once you've run a comparison, the practical workflow is to scan for color rather than re-reading every line. In a diff with a change counter and prev/next navigation, jumping directly between changed sections is faster than scrolling through a long document looking for color by eye — useful when you're reviewing a long contract redline or a large code file where most lines are unchanged.
Before comparing, messy input can bury real changes under noise — trailing whitespace, inconsistent line order, or mixed-case headers that don't actually mean anything changed. A cleanup toolbar with options like sort lines, remove blank lines, trim whitespace, and lowercase-conversion lets you normalize both texts first, so the diff that follows reflects only meaningful edits. Once you're happy with the result, options to copy it, download it as a .txt file, or copy a shareable link make it easy to attach the diff to a code review or hand it to a colleague.