People reach for a diff when the stakes of missing a change are higher than the effort of comparing by eye: a contract clause reworded by a colleague, two drafts of a policy document, a paragraph copied between two versions of a page that should match but might not. A word by word read through misses small changes constantly, especially in longer documents, while a line based diff catches every one.
The comparison runs entirely in your browser using a longest common subsequence algorithm, the same category of algorithm behind the diff shown in most version control tools. Neither piece of text is uploaded anywhere, which matters when you are comparing a confidential contract or an unreleased document.
Reading the output of this text diff checker
Each line from either text is shown once, coloured by what happened to it. A line that appears only in the original is marked as removed. A line that appears only in the edited version is marked as added. A line that appears in both, in the same relative position within the matched sequence, is marked as unchanged and shown without emphasis so your eye is drawn straight to what actually differs.
- Removed: present in the original text, missing from the edited text.
- Added: present in the edited text, missing from the original text.
- Unchanged: present in both texts in the same relative order, shown without highlighting.
- A live count above the result totals each category, so you know at a glance how large the edit was.
Why this is a line by line text comparison rather than character by character
Comparing character by character produces a diff that is technically correct but painful to read, since a single inserted word shifts every character after it and can make an entire paragraph appear changed even though only a few words moved. Comparing line by line matches how most documents, code and structured text are actually edited, as whole lines added, removed or left alone, which is why every major version control system diffs by line rather than by character.
The tradeoff is that two lines differing by a single character, for example a corrected typo, are shown as one full line removed and one full line added rather than a highlighted single character change within an otherwise unchanged line. For catching that a line changed at all, which is what most proofreading and review work actually needs, this is the right level of detail.
How the matching algorithm decides what counts as unchanged
This text diff checker finds the longest common subsequence between the two texts, the longest list of lines that appears in both texts in the same relative order, though not necessarily as consecutive lines in either one. Every line in that shared sequence is marked unchanged. Every remaining line in the original that is not part of it is marked removed, and every remaining line in the edited text is marked added.
This is a genuinely different approach from simply checking whether each line exists somewhere in the other text, which would wrongly mark a moved line as unchanged even when its position shifted relative to everything around it. Respecting order is what makes the diff checker online result match what a careful human reviewer would actually flag as changed.
Practical uses for comparing two texts
Beyond catching accidental changes, a diff is useful any time you want to confirm two things are identical rather than merely similar, for example checking that a translated legal clause matches an approved template exactly, or that a configuration file pasted into two environments has not drifted apart. The zero added and zero removed result is itself the answer in that case, confirming the texts match rather than showing you what differs. Reviewers who need to find text differences in a contract redline lean on exactly this kind of pass before signing off.
Performance on large documents
The longest common subsequence calculation this text diff checker uses runs in time proportional to the product of the two texts' line counts, which stays fast for the vast majority of documents but can slow down noticeably on inputs of many thousands of lines each. The comparison runs after a short debounce and yields control back to the browser between steps, so the page stays responsive even while a larger comparison is still working.
How to use this text diff checker
- 1
Paste the original text
Add the starting version of the text into the first box, either by pasting it or dropping a text file.
- 2
Paste the edited text
Add the changed or newer version into the second box in the same way.
- 3
Compare the two texts
Press compare to run the line by line diff and see every added, removed and unchanged line marked clearly.
- 4
Review the counts and copy the result
Check the totals for lines added and removed, then copy or download the marked up comparison for your records.
Related tools worth bookmarking
Sources and further reading
- RFC 3284: The VCDIFF Generic Differencing and Compression Data FormatAn IETF standard for representing the difference between two versions of data, the same general problem this tool solves for text.rfc-editor.org
- MDN: ArrayThe JavaScript data structure used to hold each text's lines while the longest common subsequence is computed.developer.mozilla.org
- Unicode UAX #15: Unicode Normalization FormsExplains why visually identical text can differ at the character level, relevant to why two pasted texts sometimes show unexpected diffs.unicode.org
Frequently asked questions
Common questions about the text diff checker.
Line by line. Each line from the original and edited text is treated as a single unit when matching, which mirrors how documents and code are usually edited and keeps the result readable. A line changed by even one character is shown as one line removed and one line added rather than a partial highlight within the line.
Yes. The two texts being different lengths is the normal case, since most real edits add or remove some lines. The algorithm handles texts of any relative length, matching whatever lines the two versions genuinely share and marking the rest as added or removed depending on which side they came from.
Yes, by default a trailing space makes two otherwise identical lines count as different, since trailing whitespace is sometimes meaningful and this text diff checker does not want to silently hide a real difference. If your comparison is affected by trailing whitespace you do not care about, trim both texts before pasting them in.
No. The comparison runs entirely in your browser using JavaScript, and neither text is ever transmitted over the network. This is confirmed by checking your browser's network activity while running a comparison, which shows no outgoing request carrying either piece of text.
The diff is based on relative order, not on whether a line exists anywhere in the other text. If a line moves to a different position relative to the lines around it, the algorithm correctly treats that as the line being removed from its old position and added at its new one, rather than silently treating a repositioned line as unchanged.
There is no fixed limit, but the comparison time grows with the product of the two texts' line counts, so very large documents of many thousands of lines each will take longer than a short paragraph. For most emails, articles, contracts and configuration files, the comparison completes in well under a second.