The mechanics of text comparison
Comparing two texts is not merely a matter of reading them side by side; it is a classic computer science problem solved using dynamic programming. When you diff a document, the algorithm must find the minimal set of edits—additions and deletions—required to transform the original text into the new text.
This tool relies on the Longest Common Subsequence (LCS) algorithm. Rather than searching for exact matches, the LCS algorithm identifies the longest sequence of lines that appear in both documents in the same relative order, even if other lines are inserted between them. These matching lines serve as an anchor. Everything else is classified as either an addition or a deletion.
By anchoring the comparison to the LCS, the tool produces a clean, minimal diff that highlights exactly what changed, without cluttering the output with unnecessary rewrites of unchanged paragraphs.
Understanding the diff output
The tool renders the comparison as a color-coded table, making it easy to visually parse the exact changes made between the 'Old' and 'New' versions of the text.
Understanding the diff output (Table)
| Row Type | Color | Line Number Behavior | Meaning |
| --- | --- | --- | --- |
| Unchanged | Default | Left and Right numbers match | Line is identical in both texts |
| Added | Green | Only Right number populated | Line exists in the new text but not the old |
| Removed | Red | Only Left number populated | Line exists in the old text but not the new |
| Modified | Red & Green | Split rows | A line was deleted and a new one added in its place |
How to compare your texts instantly
The comparison engine runs entirely in your browser, providing immediate feedback without server round-trips.
Paste your original text into the Old text box.
Paste the changed text into the New text box.
Read the colored table: green rows are additions, and red rows are deletions.
Use the summary badges at the top to quickly see how many lines were added, removed, or remained unchanged.
The math behind LCS and performance
Under the hood, the LCS algorithm constructs a two-dimensional matrix to compare every line of the old text against every line of the new text. It fills this matrix by checking for matches and taking the maximum of the adjacent cells. Once the matrix is complete, it traces back from the end to the beginning to reconstruct the longest common sequence.
Because this algorithm compares every line against every other line, its time and space complexity is O(n·m), where 'n' and 'm' are the number of lines in the two documents. For typical text files, contracts, or code snippets, this computation takes milliseconds.
Line numbers and context mapping
Understanding the line number columns is critical for tracking changes across document versions. The left column displays the line number from the original (Old) text, while the right column displays the line number from the modified (New) text.
If a line is unchanged, both numbers are displayed, and they increment together. If a line is added (green), only the right column shows a number, as this line exists solely in the new text. If a line is removed (red), only the left column shows a number. This dual-column approach allows you to pinpoint exactly where a change occurred in both versions of the document, which is vital when manually updating physical copies or referencing line numbers in code reviews.
Common failure modes: Whitespace and encoding
The LCS algorithm performs exact string matching. This means it is completely unforgiving of invisible characters. If your text editor automatically converts tabs to spaces, or if a trailing space is accidentally left at the end of a line, the diff tool will flag the entire line as modified (deleted and re-added), even if the visible text looks identical.
Another common pitfall is line ending inconsistency. Windows uses CRLF (`\r\n`) for line breaks, while Unix and macOS use LF (`\n`). If you copy text from a Windows document and compare it to a Unix-formatted web string, the underlying line-ending characters will differ, potentially causing the algorithm to treat the entire block as a single massive change. To prevent these false positives, ensure your text is normalized before comparing. You can use a Find & Replace tool to strip trailing whitespace or normalize line endings.
Granularity: Line-by-line vs. word-by-word
By default, this tool operates on a line-by-line basis. If you change a single word in a 50-word paragraph, the tool will highlight the entire old line as red (deleted) and the entire new line as green (added). It does not natively highlight the specific word that changed within the line.
If you require finer, word-level granularity, you can force the algorithm to work word-by-word. To do this, pre-format your text so that every single word sits on its own line. When the tool compares the documents, it will treat each word as a discrete line, highlighting the exact words that were added or removed. If you need to normalize casing before doing a strict comparison, run your text through the Case Converter first.
Practical applications for text diffing
Contract Review: Compare an original draft of a legal agreement against a revised version sent by a counterparty to ensure no sneaky clauses were altered or removed.
Code Review: Compare an original code snippet against a modified one to verify logic changes without needing to spin up a full Git repository or IDE.
Content Editing: Compare an author's draft before and after an editor's pass. You can verify the volume of changes using a Word Counter alongside the diff tool.
Data Deduplication: If you are comparing lists of data, ensure you aren't reintroducing duplicates by running the text through a Remove Duplicate Lines tool before diffing.
Frequently asked questions
Q: What algorithm does this use?
A: A classic dynamic-programming Longest Common Subsequence (LCS) line diff. It produces a minimal set of additions and deletions between the two inputs.
Q: Does it compare word-by-word or character-by-character?
A: By default, it compares line-by-line. For finer detail, you can run the comparison on text where each word is placed on its own line.
Q: What do the line numbers mean?
A: The left column is the original line number, and the right column is the new line number. Equal rows show both; added rows show only the new number; removed rows show only the old.
Q: Is there a file size limit?
A: There is no hard limit, but very large inputs (millions of lines) can be slow because the LCS algorithm's complexity is O(n·m). Most standard documents work instantly.
Q: Is my text sent to a server?
A: No. The diff is computed entirely in your browser. Your content never leaves your device, ensuring complete privacy for sensitive documents.
Q: Why is an unchanged line showing up as deleted and added?
A: This is usually caused by invisible whitespace differences, such as trailing spaces or mismatched line endings (CRLF vs LF). The algorithm requires an exact match to consider a line unchanged.
Next steps for text analysis
Understanding how dynamic programming anchors text comparisons allows you to trust the diff output and quickly diagnose false positives caused by whitespace. By leveraging the LCS algorithm, you can confidently track changes across any text medium.
Ready to compare your documents? Head over to the Text Diff tool page. To further refine your text before comparing, check our About page to learn more about EasyText's suite of privacy-first formatting utilities.
