Text Diff Checker

About Text Diff Checker

How the Diff Algorithm Works

The tool performs a line-by-line comparison using a longest common subsequence (LCS) algorithm. The LCS approach finds the longest sequence of lines that appear in both texts in the same order, then marks everything outside that sequence as either an addition or a deletion. This is the same fundamental technique behind git diff and most version control systems.

The concept dates back to 1974 when Douglas McIlroy wrote the original diff utility for the 5th Edition of Unix at Bell Labs. McIlroy and James W. Hunt later published the algorithm formally in a 1976 Bell Labs technical report (Computing Science Technical Report #41). In 1986, Eugene Myers improved on this with his O(ND) difference algorithm, published in the journal Algorithmica, which performs especially well when differences between the two inputs are small. The Myers algorithm is the default diff engine in Git today.

The basic LCS dynamic programming approach has a time complexity of O(mn), where m and n are the line counts of the two inputs. For a 500-line file compared against a 600-line file, that means roughly 300,000 operations - fast enough to run in your browser without any noticeable delay.

Colour	Meaning	Symbol (unified diff)
Red background	Line exists in the original but not in the modified version (deleted)	- (minus)
Green background	Line exists in the modified version but not in the original (added)	+ (plus)
No highlight	Line is identical in both versions (unchanged)	(space)

A line that was edited (not purely added or removed) appears as a deletion of the old wording plus an addition of the new wording. This matches how standard diff tools represent changes and makes it clear exactly what text was swapped out.

Worked Example

Original text (left panel):

The quick brown fox
jumps over the lazy dog
and runs away

Modified text (right panel):

The quick red fox
jumps over the lazy dog
and walks away
slowly

Result: The diff finds that "jumps over the lazy dog" is unchanged (it appears in both). Line 1 changed from "The quick brown fox" to "The quick red fox", so the tool shows the old version in red and the new version in green. Line 3 changed from "and runs away" to "and walks away", which again shows as a red deletion and green addition. "slowly" is a brand new line and appears only in green. In total: 2 removed lines, 3 added lines, 1 unchanged line.

Diff Granularity Levels

Different diff tools operate at different levels of detail. Understanding these levels helps pick the right tool for the job:

Granularity	How It Works	Best For	Drawback
Line-level (this tool)	Compares whole lines as single units	Code, config files, structured data, lists	A single-character change marks the entire line as changed
Word-level	Tokenises lines on whitespace, compares individual words	Prose, documentation, legal text	Can be visually busy with many small edits
Character-level	Compares individual characters	Finding exact typos, small punctuation changes	Very noisy on large blocks of changed text
Sentence-level	Splits text on sentence boundaries, compares sentences	Natural language documents, translations	Needs reliable sentence detection

Line-level comparison is the default in Git and most version control tools because source code is naturally line-oriented. Each statement, declaration, or directive typically occupies its own line, so a line-level diff captures changes at the right level of detail for code review. For prose and natural language, word-level or character-level diffing often produces more readable output because a single spelling correction inside a long paragraph would otherwise highlight the entire paragraph as changed at the line level.

Common Use Cases

Scenario	Original (left)	Modified (right)	What to Look For
Editing a document	First draft	Revised draft	What the editor changed, added, or removed
Code review	Previous version of a file	Updated version	What was changed and whether it looks correct
Config comparison	Production config	Staging config	Environment-specific differences
API response debugging	Expected response	Actual response	Which fields differ from what you expected
Translation QA	Source language text	Previous version of translation	What has changed in the source that needs re-translation
Legal document review	Original contract	Revised contract	Clauses that were added, removed, or modified
Database migration	Old schema DDL	New schema DDL	Columns added, types changed, constraints modified

As of 2025, over 93% of developers worldwide use Git as their primary version control system, according to the Stack Overflow Developer Survey. GitHub alone saw nearly 1 billion commits pushed in 2025, and every one of those commits involves a diff. Browser-based diff tools fill the gap when you do not have a local Git repository or need to compare arbitrary text that is not under version control.

Diff Output Formats Explained

Different tools present diffs in different formats. Understanding them helps when working with version control or reviewing changes from collaborators:

Format	Description	Used By
Side-by-side (this tool)	Old and new text shown in parallel columns with colour highlighting	GUI diff tools, code review interfaces
Unified diff	Single output with + and - prefixes, context lines around changes	git diff, patch files, pull requests
Inline diff	Changes shown within lines using colour or markup	Google Docs suggestions, Word track changes
Context diff	Shows blocks of context around each change with *** and ---	Older Unix tools, some patch formats

The unified diff format is by far the most common in modern development. A unified diff starts with file headers (--- and +++), followed by "hunks" that begin with @@ markers showing line numbers. Each changed line is prefixed with + or -, and unchanged context lines have a space prefix. This compact format is what GitHub, GitLab, and Bitbucket all use for pull request reviews.

How Diff Algorithms Compare

Several algorithms exist for computing diffs. Each has trade-offs in speed, output quality, and the kinds of changes it handles best:

Algorithm	Published	Time Complexity	Strength
Hunt-McIlroy	1976, Bell Labs	O(mn log m)	First practical diff algorithm, proven correct against LCS
Myers	1986, Algorithmica	O(ND)	Fast when differences are small - default in Git
Patience	Bram Cohen (Bazaar VCS)	O(N log N) typical	Better output for code - matches unique lines first, avoids jumbled diffs
Histogram	2010, JGit (Shawn Pearce)	O(N) typical	Improved Patience variant, fast for large files with many duplicates

This tool uses the LCS dynamic programming approach, which produces output equivalent to Hunt-McIlroy for standard text inputs. Git defaults to the Myers algorithm but supports git diff --diff-algorithm=patience and git diff --diff-algorithm=histogram for alternative output.

Tips for Effective Comparisons

Tip	Why
Normalise whitespace first	Trailing spaces and tab-vs-space differences create noise that hides real changes
Compare similar line lengths	If one version has word-wrapped lines and the other does not, every line will show as changed
Sort lists before comparing	Reordered items show as deletions plus additions; sorting first reveals only actual content changes
Use consistent line endings	Windows (CRLF) vs Unix (LF) line endings can make identical content appear different
Trim boilerplate	Headers, footers, and timestamps change between every export and flood the diff with noise
Compare smaller chunks	Splitting a large document into sections and diffing each one separately makes changes easier to review

Common Mistakes When Comparing Text

Even experienced developers run into misleading diff results. Here are the most frequent causes and how to handle them:

Invisible character differences. Unicode has many whitespace characters beyond the standard space - non-breaking spaces (U+00A0), zero-width spaces (U+200B), and others. These look identical on screen but register as completely different characters to the diff engine. If two lines look the same but the diff marks them as changed, invisible characters are the likely cause.

Encoding mismatches. Text saved as UTF-8 and text saved as ISO-8859-1 (Latin-1) can look identical for English text but differ for accented characters. The same letter "e" with an accent can be encoded differently depending on the file's character encoding. Standardising both inputs to UTF-8 before comparing prevents false positives.

Line ending differences. Windows uses CRLF (carriage return + line feed), Unix and macOS use LF only, and legacy macOS (pre-OS X) used CR only. If one file uses CRLF and the other uses LF, every single line will appear as changed even though the visible content is identical. Git handles this with its core.autocrlf setting, and this tool's browser-based comparison is unaffected by line endings in most cases since JavaScript's split('\n') handles both.

Reformatted vs changed content. Running a code formatter (like Prettier or Black) on one version but not the other will produce a massive diff even if the logic has not changed at all. To focus on meaningful changes, compare formatted-to-formatted or unformatted-to-unformatted.

For making bulk text changes before or after comparing, the find and replace tool supports plain text and regex patterns. To check word counts in each version, the word counter shows totals and reading time. To clean up whitespace before a comparison, the whitespace remover strips trailing spaces, extra blank lines, and invisible characters.

Sources

• Hunt, J.W. and McIlroy, M.D. - An Algorithm for Differential File Comparison (Bell Labs, 1976)
• Myers, E.W. - An O(ND) Difference Algorithm and Its Variations (Algorithmica, 1986)
• Wikipedia - Longest Common Subsequence
• Git Documentation - git-diff