ToolSite
All posts

How to Compare Two Text Files Line by Line

Learn how to compare text files line by line with diff algorithms. Understand unified diffs, side-by-side views, and spot changes instantly with our free tool.

By ToolSite5 min readguides

When You Need a Diff

You have two versions of a config file and need to know what changed. A test output doesn't match the expected output. A code snippet from a colleague differs from yours by three characters you can't spot by eye. This is what a line-by-line diff is for.

A diff tells you three things: which lines were added, which were removed, and where the changes happened. The algorithm finds the minimal set of edits that transforms the old file into the new file.

How Diff Algorithms Work

The classic approach is the longest common subsequence (LCS) algorithm. Given two sequences of lines, it finds the longest subsequence present in both. Everything before the LCS was removed from the old file. Everything after the LCS was added to the new file.

Real diff tools (GNU diff, git diff, and the Diff Checker) use variations of the Myers diff algorithm, which is faster and produces more intuitive output for human readers.

The Myers algorithm, published by Eugene Myers in 1986, works by finding the shortest edit script between two sequences. It represents the diff as a path through an edit graph where horizontal moves are deletions and vertical moves are insertions. The shortest path is the minimal diff. This is the algorithm behind git diff, GitHub's pull request view, and nearly every modern diff tool.

Reading a Line-by-Line Comparison

Here is a side-by-side diff of two short text files:

Original                  Changed
─────────────────────────────────────────
const host = "localhost"; const host = "0.0.0.0";
const port = 3000;        const port = 3000;
const debug = true;       const debug = false;
                          const logLevel = "info";

Three changes:

  1. "localhost" changed to "0.0.0.0" (line 1)
  2. true changed to false (line 3)
  3. A new line was added (line 4)

In inline diff format, this would appear as removed lines (prefixed with -) and added lines (prefixed with +):

-const host = "localhost";
+const host = "0.0.0.0";
 const port = 3000;
-const debug = true;
+const debug = false;
+const logLevel = "info";

Unified Diff Format

The diff -u output (unified diff) is the standard format used by git diff and patch tools. It includes context lines to show where the change sits in the file:

--- old.js  2026-08-01 10:00:00
+++ new.js  2026-08-05 14:30:00
@@ -1,4 +1,5 @@
-const host = "localhost";
+const host = "0.0.0.0";
 const port = 3000;
-const debug = true;
+const debug = false;
+const logLevel = "info";

The @@ -1,4 +1,5 @@ header means: the old file, starting at line 1, shows 4 lines of context; the new file, starting at line 1, shows 5 lines. Context lines (no + or -) help you locate the change in the original file.

Word-Level vs Character-Level Diffs

Most diff tools operate on lines. A one-character change on a line highlights the entire line as changed. Word-level diff highlights the specific word or character that changed within the line.

Compare these two approaches for the change from hello world to hello World:

Line-level diff:

-hello world
+hello World

Word-level diff:

hello [-w-]{+W+}orld

The word-level version pinpoints the exact change. This matters when diffing long lines like minified JSON or complex SQL queries where a single-character change is buried in 200 characters of identical text.

Diff Tools and When to Use Them

  • Terminal: diff file1.txt file2.txt or git diff for staged changes. Fast, always available, no UI needed. Use diff -u for unified format or diff -y for side-by-side view.
  • VS Code / editor: open both files, right-click, "Compare Selected". Best for code reviews within the editor. The inline highlighting makes small changes obvious.
  • Browser tool: Diff Checker when you just have two snippets and don't want to create temporary files. Paste both sides, see the differences highlighted inline.

Common Use Cases

  • Reviewing pull requests: every PR review is a diff between the base branch and the feature branch. Understanding diff output is a core developer skill.
  • Debugging config changes: a server config worked yesterday and doesn't work today. Diff yesterday's backup against today's file.
  • Comparing API responses: two API calls that should return identical data don't. Diff the JSON outputs. For deeply nested JSON, prettify both sides first with a JSON formatter so the diff aligns structurally.
  • Checking test output: your test expected one string and got another. Diff them to find the mismatch character.
  • Auditing code changes: before committing, git diff shows everything you're about to commit. This is your last chance to catch debugging print statements, hardcoded credentials, and accidental deletions.

Pitfalls When Comparing Files

Whitespace noise: trailing spaces, tabs vs spaces, and blank line differences show up as changes even when the meaningful content is identical. Use diff -w (ignore whitespace) or git diff -w to filter it out.

Line ending mismatches: a file with CRLF (Windows) line endings will show every line as changed when compared to an LF (Unix) file. Configure your editor or .gitattributes to normalize line endings.

Encoding confusion: comparing a UTF-8 file with a UTF-16 file produces garbage output. Most diff tools require both files to use the same encoding.

Try it yourself: open the Diff Checker. Paste hello world in the left panel and hello World (capital W) in the right panel. The word-level diff highlights the exact character change. Then paste a small function with one line changed and observe how the diff marks additions (green) and removals (red).

Related Reading