Spot every change between two versions
Comparing two versions of anything by eye is slow and unreliable. A renamed variable, a reworded clause or a deleted line hides easily in a wall of text, and the longer the document, the more likely you are to miss one. A diff does the comparison mechanically: paste the original on the left, the changed version on the right, and every added line is tinted green with a + prefix while every removed line is tinted red with a − prefix. Unchanged lines stay plain so your eye goes straight to what moved.
The counts above the output tell you the shape of the change at a glance. Two long documents that differ by one edited paragraph will show a handful of added and removed lines, not hundreds, because the tool finds the longest run of lines the two versions still share and only reports what falls outside it.
Everything runs in your browser. Neither version of your text is uploaded, stored or seen by anyone, so it is safe to compare contracts, config files, code or anything else you would rather keep private.
Reading the output
That red-next-to-green pairing is how a diff shows an edit. The comparison works line by line, so it does not try to say which words within the line changed; the old line goes, the new line arrives, and seeing them adjacent makes the actual edit obvious.
How the comparison works
Under the hood the tool splits both texts into lines and computes the longest common subsequence, usually shortened to LCS. That is the longest sequence of lines that appears in both versions in the same order, though not necessarily next to each other. Once that shared backbone is known, everything in the original that is not part of it must have been removed, and everything in the changed version that is not part of it must have been added. This is the same idea that powers version control systems such as Git, which is why the + and − notation here will feel familiar if you have ever read a pull request.
Because lines only count as equal when they match exactly, invisible differences are treated as real ones. A trailing space, a tab instead of spaces, or a capital letter is enough to mark a line as changed. That strictness is usually what you want in code and config, but if whitespace noise is drowning out the real edits, clean both versions first and then compare.
When a line diff is the right tool
Line-based comparison shines wherever text has natural line structure: source code, CSV exports, server config, lists of names or SKUs, and legal or policy documents drafted one clause per line. It is the quickest way to answer questions like "what did the supplier actually change in this price list?" or "which settings differ between staging and production?".
It is less suited to prose that has been rewrapped, because rewrapping changes where the line breaks fall and every affected line then reads as changed. For flowing paragraphs, put each sentence or paragraph on its own line in both versions before comparing, and the diff will come out clean. For very large inputs the tool caps the comparison to keep your browser responsive and will ask you to compare smaller sections instead.
Frequently asked questions
Is my text uploaded anywhere?
No. The comparison runs entirely in your browser with JavaScript. Neither version of your text is uploaded, stored or seen by anyone, which makes it safe to compare contracts, code or anything else confidential.
How does the comparison actually work?
The tool splits both texts into lines and finds the longest common subsequence, the longest run of lines the two versions share in the same order. Everything outside that shared backbone is reported as added or removed. It is the same idea used by version control tools such as Git.
Why does an edited line show as one removed plus one added?
The comparison works line by line, so a line that changed is treated as the old line going and a new line arriving. That pairing of a red line and a green line next to each other is the standard way diffs show an edit.
Does the diff ignore spaces or capitalisation?
No. Two lines only count as the same if they match exactly, including spaces, tabs and case. If stray whitespace is creating noise, tidy both versions with the remove extra spaces tool first and then compare them.
Is there a limit on how much text I can compare?
For very large texts, roughly a couple of thousand changed lines on each side, the tool will ask you to compare smaller sections instead. Unchanged beginnings and endings are skipped efficiently, so long documents with few edits compare without any trouble.