A diff shows what changed between two versions: what was added, what was removed, and what stayed put. It is the fastest way to answer “what did they actually change?” about a contract, a draft, a configuration file or a piece of copy that came back from review with no track changes turned on.
How a diff is computed
The underlying problem is finding the longest common subsequence — the largest set of lines or words appearing in both versions in the same order. Whatever is not in that shared sequence is an insertion or a deletion.
A consequence worth knowing: a diff has no concept of a move. Relocate a paragraph and the algorithm sees a deletion in one place and an addition in another, not a single move. This is why reordering sections produces a diff that looks far more alarming than the change actually was.
Similarly, there is no concept of an edit. Changing one word in a line is shown as the whole line removed and a new line added, unless the comparison is done at word level.
Line diff or word diff
Line-level comparison is the right choice for code, configuration, CSV data and anything where line breaks are meaningful. It is what version control uses.
Word-level comparison is better for prose. A paragraph is often a single long line, so a line diff on prose reports “this entire paragraph changed” when one adjective moved. Word-level shows you the adjective.
For editorial work, word-level is almost always what you want.
Whitespace
Most of the noise in a real diff is whitespace: trailing spaces, tabs converted to spaces, Windows line endings (CRLF) against Unix ones (LF), or an editor that reformatted on save. Ignoring whitespace usually reveals a small substantive change hiding behind a large cosmetic one.
The exception is any format where whitespace is significant — Python, YAML, Markdown — where an ignored space can be the actual bug.
Practical uses
- Contract review. Comparing a returned draft against the version you sent, when the other side has helpfully flattened all the tracked changes.
- Copy review. Finding what the client changed in the document they said they had “just tidied up”.
- Configuration debugging. Comparing a working config against a broken one. This finds the cause far faster than reading either.
- Checking for plagiarism between two specific documents. A diff will show you overlapping passages — though it only compares the two texts you give it, and is not a search of the web.
- Verifying a paste. Confirming that text survived a copy between systems intact, particularly where smart quotes or non-breaking spaces may have been introduced.
Where people go wrong
Reading a reordered document as heavily rewritten. Check whether the “added” text is identical to something “removed” elsewhere before panicking.
Diffing text with different line endings. Everything shows as changed. Normalise first.
Assuming identical output means identical files. Invisible characters — non-breaking spaces, zero-width joiners, byte-order marks — can be present without appearing in a rendered diff. If two texts look identical but behave differently, that is usually why.
Diffing very large texts in a browser tab. The algorithm is quadratic in the worst case. For very long documents, compare section by section.
Both texts are processed entirely in your browser and never transmitted — which is what makes this safe to use on a confidential draft. See the privacy policy.