Text Diff Checker

How diff algorithms work

At its core, a diff algorithm solves the Longest Common Subsequence (LCS) problem. Given two sequences — call them A and B — the algorithm finds the longest sequence of elements that appears in both A and B in the same order, even if not contiguous. Everything in A that is not in the LCS was deleted; everything in B that is not in the LCS was inserted.

For text comparison, the "elements" are lines. Line 1 of file A is compared to line 1 of file B, then line 2, and so on. The algorithm produces an edit script: a minimal sequence of delete and insert operations that transforms A into B.

The naive LCS algorithm runs in O(m × n) time and O(m × n) space, where m and n are the number of lines in each file. For a 10,000-line file compared against itself with 50 changes, that is 100 million cells of memory — impractical in a browser. This is why production diff tools use optimized algorithms like Myers.

The Myers algorithm — why Git uses it

Eugene Myers published his diff algorithm in 1986 in a paper titled "An O(ND) Difference Algorithm and Its Variations." N is the number of lines in both files combined, D is the number of differences (the edit distance). The algorithm runs in O(ND) time and O(D) space for its core loop, making it dramatically faster than naive LCS when files are mostly similar — which is almost always true for code changes.

The intuition: Myers diff explores a "edit graph" where moving right means consuming a line from the original (a delete), moving down means consuming a line from the modified (an insert), and diagonal movement means the lines are equal (no cost). Finding the shortest edit script is equivalent to finding the shortest path from the top-left corner to the bottom-right corner of this graph. Myers does this with a greedy breadth-first search, layer by layer, expanding the frontier of edit distance D before trying D+1.

Git, GNU diff, GitHub, GitLab, Bitbucket, and virtually every code review tool use Myers diff by default. When you run git diff, you are seeing the output of the Myers algorithm. Git also offers alternative algorithms (--diff-algorithm=patience or --diff-algorithm=histogram) for cases where Myers produces confusing output, but Myers is the default because it is fast and produces compact diffs.

When to use a text diff tool

A browser-based diff tool is most useful for quick, one-off comparisons where you do not want to switch to a terminal:

• Config file comparison — paste two versions of an nginx.conf, a Dockerfile, or a .github/workflows YAML to spot which lines changed between environments.
• API response comparison — copy two JSON or XML responses and diff them to find what changed between API versions or between staging and production. For JSON specifically, use the JSON Diff tool — it normalizes formatting before diffing, so cosmetic whitespace changes do not pollute the output.
• Log file analysis — diff two application logs to identify new error lines that appeared after a deployment.
• SQL query comparison — paste two versions of a complex query to see which clauses changed.
• Documentation review — compare the before and after of a README or documentation page before submitting a pull request.

Reading diff output

This tool uses a side-by-side view. The original text is on the left, the modified text is on the right. Line numbers appear in both columns so you can orient yourself in large files.

The color coding follows the universal convention from terminal diff tools:

• Red / − (minus) — lines that exist in the original but were removed in the modified version.
• Green / + (plus) — lines that exist in the modified version but were not in the original.
• No color — lines that are identical in both versions (context lines).

When a line was modified — deleted from one side and inserted on the other — the tool pairs them side by side. The left side shows the original version of that line in red; the right side shows the new version in green. This pairing makes it easier to read what a line changed to, rather than showing the deletion and insertion as unrelated events.

The stats bar above the diff shows a summary: how many lines were added, how many were removed, and how many are unchanged. Use this to gauge the scope of the change at a glance before reading line by line.

Command-line diff tools

For large files, scripted comparisons, or integration into CI pipelines, command-line diff tools are the right choice:

# Basic unified diff (most common format)
diff -u original.txt modified.txt

# Side-by-side (like this tool)
diff -y original.txt modified.txt

# Ignore whitespace changes
diff -b original.txt modified.txt

# Recursive directory diff
diff -rq dir1/ dir2/

# Output just the files that differ
diff -rq dir1/ dir2/ | grep "^Files"

The unified diff format (diff -u) is the standard format for patches. Lines beginning with - were removed, lines with + were added, and lines with a space are context. This is the format that git apply and patch consume.

diff vs git diff — key differences

GNU diff compares two files or directories on disk. git diff compares versions tracked by Git — it has richer semantics because it understands commits, branches, and staging.

# Compare working tree to last commit
git diff

# Compare staged changes to last commit
git diff --staged

# Compare two commits
git diff abc1234 def5678

# Compare two branches
git diff main..feature/my-branch

# Compare a specific file between branches
git diff main..staging -- src/app.js

# Use git diff to compare two files outside a repo
git diff --no-index original.txt modified.txt

The --no-index flag is particularly useful: it lets you use git diff's output formatting and color coding to compare any two files, even outside a Git repository. This gives you the same experience as this browser tool but in the terminal.

Using diff for API regression testing

One of the highest-value uses of text diff in a development workflow is API regression testing: comparing the response from your current API against a known-good "golden" response to detect unintended changes. This is especially valuable when refactoring code that touches serialization, business logic, or database queries.

A simple shell-based regression test looks like this:

# Save a golden response
curl -s https://api.example.com/v2/users/42 | jq -S . > golden.json

# After your change, compare
curl -s https://api.example.com/v2/users/42 | jq -S . > current.json
diff golden.json current.json

The jq -S . flag sorts keys alphabetically before saving, which means cosmetic differences in key order do not produce false positives. A clean diff (no output) means your change did not alter the API response.

For more structured API testing — with assertions, test suites, mock servers, and CI integration — tools like Postman provide a full testing framework. Postman's collection runner can execute test scripts against multiple environments, compare responses programmatically, and fail CI builds when regressions are detected. For error monitoring when something slips through, Sentry captures and groups production exceptions with full stack traces, letting you correlate a spike in errors with a specific deployment.

Frequently Asked Questions