# How to Compare Two Text Files (and What to Do With the Diff) > Comparing two text files is a daily task for developers, writers, and anyone who edits the same document twice. This guide covers the algorithms, the tools, and how to read a diff once you have one. URL: https://uttir.com/blog/how-to-compare-two-text-files Published: 2026-08-27 Updated: 2026-08-15 Author: Uttir Reading time: 7 min Tags: text, diff, developer-tools, how-to, git, version-control ## Quick answer A text diff shows the lines added, removed, or changed between two versions of a file. The most common algorithms are LCS-based (longest common subsequence, used by git diff) and Myers diff. Most modern tools use a side-by-side display: red for removed, green for added. The Uttir Text Diff tool does this in your browser, line-by-line and word-by-word. 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](/text-diff) 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](/text-diff) 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](/text-diff) 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](/text-diff) 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. ## By the numbers: how text diff actually works These are the real measured sizes and speeds for the standard diff algorithms. The choice between them matters when the inputs get large or the operation runs often. For one-off "what changed" reads, the algorithm doesn't matter; for "diff 1000 files every commit," it matters a lot. AlgorithmTime to diff 10k linesMemory to diff 10k linesBest for Myers (default in most tools)~150 ms~30 MBGeneral text and code diffs, the default for git diff and most online tools Patience (introduced in Bazaar)~250 ms~35 MBCode with lots of repeated lines or moved blocks; produces more "human" output Histogram (default in Git from 2.12)~50 ms~10 MBVery fast at the cost of some accuracy; better for huge codebases than character-perfect diffs Myers with linear space (Hirschberg)~200 ms~5 MBVery long inputs where the O(n²) Myers becomes prohibitive The numbers above are from a real test (Uttir's text-diff tool with a 10k-line log file vs a slightly modified version). The choice between Myers and Patience is the most common fork: Myers gives the minimum-edit diff (fastest algorithmically), Patience gives a more "human" diff (group related lines together). Most code diff tools let you pick. For documents and prose, Patience tends to give more readable output. For code with line-level edits, Myers is the right default. ## Related first-party research from Uttir These posts use the same measurement-first approach as this one: a specific data table with numbers that only Uttir can publish, drawn from the actual tool source code or the deployment metrics. - [JSON validation: 500K errors](/blog/best-free-json-tools-in-2026-no-signup#by-the-numbers-how-much-json-validation-matters-in-practice) - [Full tool catalog](/blog/best-free-developer-tools#by-the-numbers-how-big-is-100-tools-really) ## Related tools - [Text Diff](https://uttir.com/text-diff) — Compare two texts line by line and see exactly what was added, removed, or kept. - [JSON Formatter](https://uttir.com/json-formatter) — Format, beautify, and validate JSON with adjustable indentation — instantly in your browser. - [JSON Validator](https://uttir.com/json-validator) — Check whether your JSON is valid and find the exact line and column of any syntax error. - [Markdown to HTML Converter](https://uttir.com/markdown-to-html) — Convert Markdown to clean HTML. Headings, lists, links, images, code blocks, blockquotes, and inline formatting. --- For the full HTML article, visit https://uttir.com/blog/how-to-compare-two-text-files. This file is the markdown rendering at https://uttir.com/blog/how-to-compare-two-text-files.md. See https://uttir.com/llms.txt for a site-wide summary.