How to Compare Two Text Files (and What to Do With the Diff)

Comparing two text files is one of the most common tasks in software, writing, and document work. "What changed between the old version and the new version?" is a question that comes up hundreds of times a day across the industry. This guide covers the algorithms, the tools, and how to read a diff once you have one.

What is a diff?

A diff is a structured representation of the changes between two texts. The simplest form: a list of operations (insert, delete, keep) that transform the first text into the second. The most common output: a side-by-side or inline view where unchanged lines are normal, added lines are green, and removed lines are red.

Diff is short for "difference" — the term has been in use since the 1970s in computer science, with the first Unix diff command written by Douglas McIlroy in 1974.

The algorithms

Most diff tools use one of two algorithms under the hood:

LCS (Longest Common Subsequence)

The LCS algorithm finds the longest sequence of items (usually lines) that appears in both files in the same order. Everything not in the LCS is either added (in the new file) or removed (from the old file). The output is a minimal diff — the smallest set of changes that explain the difference. LCS is the algorithm used by the original Unix diff and by most modern tools.

LCS is O(N×M) in time and space, where N and M are the line counts. For most files, that is fast enough. For very large files (10,000+ lines), Myers diff (used by Git) is faster in practice, even though it has the same worst-case complexity.

Myers diff

The Myers algorithm (1986) is what Git uses. It finds the shortest edit sequence (SES) — the minimum number of insertions and deletions to transform one text into the other. For most inputs, Myers and LCS produce the same output. The advantage of Myers is better average-case performance on real-world inputs (where changes are clustered, not scattered).

Patience diff

The Patience diff is a variant that uses a different heuristic: it finds common lines that are unique in both files, anchors the diff on those, and recursively diffs the regions in between. The output is often more readable for code diffs where the LCS-based approach can produce "noisy" matches (lines that look common but are actually different). Git supports Patience diff via git diff --diff-algorithm=patience.

How to read a diff

Most diff tools show a side-by-side or inline view. The colors are standardized:

• Green — added lines (in the new file, not in the old).
• Red — removed lines (in the old file, not in the new).
• No color — unchanged context lines.

The line numbers on the left are from the old file; on the right, from the new. A diff like:

  12   unchanged line A
  13 - removed line B
  14   unchanged line C
  15 + added line D
  16   unchanged line E

means line 13 was removed, line 14 is unchanged (and was line 14 before, line 13 after), and line 15 was added.

Unified vs side-by-side

Unified diff (the diff -u format) shows added and removed lines inline, with - and + prefixes. This is the format used by git diff and the format that gets sent in code reviews.

Side-by-side diff shows the old and new versions in two columns. Easier to scan visually, especially for non-technical users. Most web-based diff tools use this format.

Both are the same data. Pick the one you can read faster.

Word-level and character-level diffs

Line-level diffs are coarse: a single-character change shows as one line removed and one line added. Word-level and character-level diffs go inside the line and highlight the exact changes:

Old: The quick brown fox jumps over the lazy dog.
New: The quick brown cat jumps over the lazy dog.
                                         ^^^
                                         changed

This is what you want for prose, where most edits are small changes to a few words, not full-line replacements. The Uttir Text Diff tool does both line-level and word-level diffs in your browser.

Tools for diffing text

Command line

The Unix diff command has been the standard since 1974. Today, git diff is the most-used diff tool in software. The basic syntax:

diff old.txt new.txt
diff -u old.txt new.txt          # unified format
diff -y old.txt new.txt          # side-by-side
git diff                          # working tree vs last commit
git diff HEAD~1                   # last commit vs the one before
git diff main feature-branch      # branch comparison

GUI tools

Most code editors (VS Code, Sublime, IntelliJ) have a built-in diff view. Beyond Compare and DiffMerge are popular standalone tools. Meld is the standard on Linux.

Online tools

For non-developers, or for ad-hoc diffs without a code editor, a web-based diff tool is the right choice. The Uttir Text Diff tool handles up to 10 MB of text, runs in your browser, and supports both line-level and word-level diffs. It is faster than opening a code editor for a quick check.

When you should diff

Diffing is the right tool for any of these:

• Code reviews — the entire PR workflow is built on diffs. GitHub, GitLab, and Bitbucket all show diffs as the core review surface.
• Config file changes — comparing a previous known-good config to a broken one. Critical for debugging.
• Document revisions — comparing draft v1 to draft v2 of an article, contract, or report.
• CSV / data file changes — comparing two exports to find rows that changed.
• Generated output — comparing the output of a build to a previous build, to verify nothing unexpected changed.

Diffing is the wrong tool for binary files (images, PDFs, compiled code). For those, you need a different comparison: visual diff, byte-level diff, or semantic diff (which is much harder).

Common pitfalls

Line endings

Windows uses (CRLF). macOS and Linux use (LF). A file with mixed line endings will show up as "every line changed" in a diff, even if the content is identical. Fix: normalize line endings before diffing. Most editors have a "convert to LF" option. The Uttir Text Diff tool normalizes line endings automatically.

Trailing whitespace

An editor that strips trailing whitespace on save will create a "noise" diff: every line that previously had trailing whitespace now shows as changed. Fix: configure the editor to either always strip or never strip, consistently across the team.

Tab vs space indentation

A file with tabs in one version and 4 spaces in the other will show as a complete rewrite in a diff. Fix: pick one and use it. Most projects standardize on spaces; the .editorconfig file makes this enforceable.

Huge files

Diff is O(N×M) in the worst case. For two 100 MB files, the algorithm will be slow. For binary files, it will be wrong. If you need to diff large files, look for a streaming diff tool (rsync with --checksum, git diff on text files only, or a specialized binary diff).

Beyond two files: 3-way merges and merge conflicts

A 3-way merge takes three files: yours, theirs, and the common ancestor. The tool produces a merged version that combines both. When the changes overlap (both you and they changed the same line), the result is a merge conflict — both versions are kept, marked with <<<<<<<, =======, and >>>>>>>, for the user to resolve manually.

Git does 3-way merges automatically for most changes. The conflicts you see in git status as "unmerged paths" are the cases where the auto-merge failed and human input is required. Most modern editors (VS Code, IntelliJ) have a built-in 3-way merge UI that shows all three files side by side and lets you pick which version to keep.

Bottom line

Comparing two text files is a solved problem with great tools. The Uttir Text Diff tool handles the everyday case (paste two snippets, get a side-by-side diff) in your browser. For code, use git diff. For everything else, a quick paste into a web tool is the fastest path.