Text Diff Checker

Text Diff: Free Online Side-by-Side Text Comparison and Difference Finder

Comparing two versions of text "” a configuration file before and after editing, two similar documents that need to be reconciled, code with and without a proposed change, translated content against an original "” is a fundamental task in software development, technical writing, and content management. Our free online text diff tool shows you exactly what changed between two text blocks using a clear, color-coded diff view with line-by-line and character-level comparison, highlighting additions in green and deletions in red.

All comparison runs in your browser "” no text content is sent to any server. Paste two versions of any text, click compare, and instantly see every addition, deletion, and modification clearly highlighted. Choose between side-by-side view (two panels showing both versions simultaneously) and unified view (single panel with changes interleaved, like git diff output). Supports any text content: code, configuration files, prose documents, log files, JSON, YAML, CSV data, and more.

What Is a Text Diff?

A "diff" (short for difference) is a representation of what changed between two versions of a text file or string. The concept comes from the Unix diff command, first released in 1974, which compares two files and outputs the changes needed to transform one into the other. This output format became the foundation of version control systems and collaborative editing tools.

The core algorithm underlying most diff tools "” including our web-based tool "” is the Longest Common Subsequence (LCS) algorithm, which finds the maximum number of lines (or characters) that appear in the same relative order in both texts. Lines not in the LCS are classified as either additions (in the new version but not the old) or deletions (in the old version but not the new).

Modern diff implementations use variations and optimizations of the LCS algorithm to handle large files efficiently: Eugene Myers' O(ND) diff algorithm, the Patience diff algorithm (used in git), and the Histogram diff algorithm (also used in git for certain file types). Each produces slightly different diffs for the same input, with tradeoffs between performance and readability of the generated diff.

Understanding Diff Output Formats

Side-by-Side Diff

The side-by-side view shows the old text on the left and the new text on the right, with corresponding lines aligned horizontally. Modified lines appear on both sides with character-level changes highlighted within each line. Additions appear only on the right side; deletions appear only on the left side. This view is best for understanding the context of each change and how corresponding sections relate to each other.

Unified Diff

The unified diff format (used by git diff) shows changes in a single column with context lines to help orient readers. Lines starting with + were added; lines starting with- were removed; lines starting with a space are context (unchanged). Context lines provide surrounding unchanged content so readers understand where in the file each change occurs.

A typical unified diff chunk looks like:

@@ -10,7 +10,8 @@
 function calculateTotal(items) {
-  let total = 0;
+  let total = 0.00;
   for (const item of items) {
-    total += item.price;
+    total += item.price * item.quantity;
   }
+  return parseFloat(total.toFixed(2));
 }

The @@ hunk header -10,7 +10,8 means: starting at line 10 in the original file (7 lines shown), starting at line 10 in the new file (8 lines shown).

Inline Diff (Character-Level)

Character-level diffing highlights changes within individual lines rather than just showing entire lines as added or removed. This is invaluable when lines differ by only a single character "” a typo, a number change, a renamed variable "” where showing the entire line as changed would obscure the small but critical difference.

Our tool performs character-level diffing within changed lines by default, similar to how GitHub highlights intra-line differences in pull request reviews.

Myers Diff Algorithm: The Foundation of git diff

Eugene Myers published the O(ND) difference algorithm in 1986. It finds the shortest edit script "” the minimum number of insertions and deletions needed to transform one string into another. This minimum edit script corresponds to the LCS approach: the more common content two texts share, the shorter the edit script.

Git uses the Myers algorithm by default (git diff --diff-algorithm=myers). Other algorithms git supports:

• Patience: identifies unique lines that appear exactly once in both files and uses them as "anchors" for the diff. Produces more human-readable diffs for code that has been reorganized. Use with git diff --patience.
• Histogram: an extension of Patience that handles low-occurrence lines more efficiently. Generally recommended over Patience for code. Use withgit diff --histogram.
• Minimal: produces the absolute minimum edit distance, often at the cost of readability. Use with git diff --minimal.

Our tool uses the Myers algorithm for line-level diff and a specialized character-level algorithm for intra-line highlighting.

The Longest Common Subsequence Problem

The LCS problem asks: given two sequences, what is the longest subsequence of elements that appears in both sequences in the same relative order, not necessarily contiguously? For text diffing, the sequences are lines (for line-level diff) or characters (for character-level diff).

Dynamic programming solves LCS in O(mn) time and space, where m and n are the lengths of the two sequences. For long files, this can be slow "” a naive implementation comparing two files with 10,000 lines each requires 100 million operations. Optimized algorithms like Myers' work in O(ND) time, where N = m + n and D = edit distance, which is much faster when files are similar (small D).

For our web-based tool, files up to several thousand lines are compared nearly instantly. Very large files (100,000+ lines) may take a few seconds due to browser JavaScript constraints.

Diff in Version Control: Git and Beyond

The diff concept is inseparable from modern version control systems. Git stores snapshots of repository state, not diffs, but displays changes as diffs for human consumption:

• git diff: changes in working directory vs staging area
• git diff --staged: staged changes vs last commit
• git diff HEAD~1: changes introduced by the last commit
• git diff branch1..branch2: differences between two branches
• git log -p: commit history with patch diffs

Code review platforms (GitHub, GitLab, Bitbucket) display pull request changes as diffs. The ability to review diffs effectively is one of the most valuable skills in collaborative software development.

Practical Applications of Text Diffing

Code Review Without Git

When you need to compare code changes outside a git workflow "” comparing two files in different repositories, comparing a file across different environments, reviewing changes made by a collaborator without git access "” our online diff tool provides the same visualization as a git diff without requiring any version control setup.

Configuration File Comparison

Infrastructure teams regularly compare configuration files across environments: production vs staging, current vs desired state, deployed version vs repository version. Configuration diffs often reveal subtle differences (different port numbers, missing environment variables, extra debugging flags) that cause "works in staging but not in production" bugs. Our tool handles YAML, TOML, INI, JSON, and any text-based configuration format.

Document Version Comparison

Technical writers, legal teams, and content creators frequently need to compare document versions: previous draft vs revised draft, contract version A vs contract version B, translated content vs original. Our tool highlights every word and character change, making revision review systematic rather than requiring careful manual reading.

Log File Analysis

Comparing log files from two time periods or two server instances helps identify what changed when a behavior changed. Comparing a known-good log against a suspicious log highlights anomalous entries. Our tool handles multi-thousand-line log files with clear visualization of added and removed log entries.

Database Schema Comparison

Comparing SQL DDL from two database instances (production vs staging, before vs after migration) reveals schema drift "” tables that exist in one environment but not another, column type differences, missing indexes. Paste two SHOW CREATE TABLE outputs or schema dumps to see exactly what changed.

API Response Comparison

When debugging API behavior changes, comparing two API responses (formatted JSON) shows exactly which fields changed, which were added, and which were removed. This is far faster than reading two JSON blobs side by side manually. Format the JSON first with our JSON formatter, then compare with our diff tool for clean, readable results.

Translation and Localization Review

Comparing translation files (JSON, YAML, PO format, Android strings.xml) against the source language file or a previous translation version shows missing translations, outdated strings, and unexpected additions.

Diff Algorithms for Code: Special Considerations

Whitespace Handling

Code diffs often produce noise from whitespace changes: converting tabs to spaces, reformatting, adding trailing newlines. Our tool offers whitespace normalization options:

• Ignore all whitespace: treats whitespace-only differences as no change
• Ignore leading whitespace: useful for indentation changes (re-indented code blocks)
• Ignore trailing whitespace: ignores trailing space/tab differences
• Ignore empty lines: treats added or removed blank lines as no change

Case Sensitivity

Case-insensitive comparison is useful for comparing natural language text or case-insensitive systems (Windows file paths, SQL keywords). Case-sensitive comparison (the default) is necessary for code, configuration, and most technical content where case is significant.

Line Ending Normalization

Files edited on different operating systems may have different line endings: \n(Unix/Linux/macOS), \r\n (Windows CRLF), or \r (old macOS Classic). When comparing files that originated on different platforms, line ending differences can make every line appear changed. Our tool normalizes line endings before comparison by default.

Semantic Diff vs Syntactic Diff

Standard text diff is syntactic "” it compares text character-by-character and line-by-line without understanding the meaning of the content. Semantic diff understands the structure of the content type and compares meaning:

• JSON semantic diff: recognizes that object key order doesn't matter and array element order does matter. Two JSON objects with the same key-value pairs in different orders are semantically identical.
• XML/HTML semantic diff: understands attribute order is irrelevant, namespace prefixes are interchangeable with consistent declarations, and equivalent empty element forms (<br/> vs <br></br>) are the same.
• AST diff (code diff): compares Abstract Syntax Trees of parsed code, finding semantic refactors (variable renaming) vs behavioral changes (logic modification).

Our tool performs syntactic text diff. For JSON semantic diff, format both JSONs with sorted keys (using our JSON formatter) before comparing "” this normalizes key order differences.

Diff Output in Code Review Workflows

Pull Request Reviews

GitHub, GitLab, and Bitbucket all display pull request changes as diffs with the same green/red color coding used in our tool. Understanding how to read diffs efficiently makes code review faster: start with the most complex changed functions, look for logical errors in the delta rather than re-reading unchanged code, and use the character-level highlighting to catch subtle bugs like off-by-one errors or swapped variable names.

Patch Files

The unified diff format is also used in "patch files" "” text files containing diffs that can be applied to transform one file version to another using the patch command. Our tool can generate patch-format output that you can save and apply withpatch -p0 < changes.patch.

Measuring Diff Complexity: Edit Distance Metrics

The edit distance between two texts can be measured in several ways:

• Levenshtein distance: minimum insertions, deletions, and substitutions to transform one string into another. Character-level for strings, line-level for files.
• Hamming distance: number of positions where two equal-length strings differ. Only applies to strings of the same length.
• Jaro-Winkler distance: similarity score 0-1 for strings, optimized for short strings like names. Not used for file diff but useful for fuzzy matching.
• Diff hunk count: number of separate changed regions. A large number of small hunks suggests scattered whitespace changes; a small number of large hunks suggests focused feature changes.

Our tool displays statistics: lines added, lines removed, characters changed, percentage similarity "” giving you a quantitative sense of how different the two texts are.

Privacy and Performance

All text comparison runs entirely in your browser using JavaScript. No text content from either input is transmitted to our servers. The diff algorithm runs locally, making it safe for comparing confidential documents, proprietary source code, personal communications, or any sensitive content. There are no file size limits imposed by server resources "” practical limits are set only by your browser's available memory (our tool handles files up to several megabytes without issues).

The diff computation uses optimized JavaScript implementations of the Myers and LCS algorithms that process most inputs in milliseconds. For very large files (tens of thousands of lines), computation may take a few seconds "” a progress indicator shows real-time status.