Free Online Text Diff Checker

Paste two blocks of text or code and instantly see every addition, deletion, and unchanged line highlighted. Great for comparing config files, code reviews, or document revisions.

Related Tools

Frequently Asked Questions

What algorithm does the diff tool use?

The diff uses the Myers diff algorithm, the same method behind git diff. It finds the minimum edit distance between two texts, producing the most human-readable diff with the fewest changes highlighted.

Can I diff code files?

Yes. Paste any two code snippets — JavaScript, Python, JSON, SQL, or any text — and the diff engine handles them the same way. Syntax is not interpreted; only line-by-line text differences are shown.

What do the colors mean?

Green highlighted lines are additions (present in the right/new text but not the left). Red highlighted lines are removals (present in the left/old text but not the right). Unchanged lines are shown in neutral color.

Text Comparison and Diff Tools: Finding Changes Efficiently

Comparing two versions of text — whether source code, documents, configuration files, or data — is a fundamental task in software development and content management. Diff algorithms identify the minimal set of changes (insertions, deletions, and modifications) that transform one text into another, presenting them in a format that makes the differences immediately visible. Understanding how diff tools work, and how to use them effectively, is essential for code review, debugging, collaboration, and content auditing.

How Diff Algorithms Work

The most widely used diff algorithm is the Myers algorithm, developed by Eugene Myers in 1986 and still the basis for git diff and most other diff tools. The algorithm finds the Longest Common Subsequence (LCS) — the longest sequence of characters or lines that appears in both texts in the same order, though not necessarily contiguously. Lines that appear in the LCS are unchanged; lines present in only the original are deletions; lines present in only the modified version are insertions. The Myers algorithm finds this solution efficiently by treating the diff problem as finding the shortest edit path through a two-dimensional grid.

Different diff tools apply this algorithm at different granularities. Line-level diffs compare entire lines as the basic unit, which is suitable for most code and text comparison. Word-level diffs highlight individual changed words within lines, providing more granular insight into what changed. Character-level diffs show every individual character that was added or removed, which is most useful for data files and configurations where small changes have significant meaning. Many modern diff tools perform a line-level diff first and then apply a word- or character-level diff within changed lines to provide both high-level context and fine-grained detail.

Unified vs. Side-by-Side Diff Formats

Diff results can be presented in two main display formats. The unified diff format (used by git diff and patch) shows changed sections of text in a single column with deleted lines prefixed by a minus sign and added lines prefixed by a plus sign, along with context lines (unchanged lines shown for reference) and hunk headers that specify the line numbers for each changed section. This format is compact, easy to email or include in commit messages, and is the standard format for patch files that can be applied to update code.

Side-by-side diff format displays the original text on the left and the modified text on the right, with corresponding changed sections aligned horizontally. This format is more intuitive for understanding the context of changes and is preferred in graphical diff tools, code review interfaces, and document comparison tools. GitHub's pull request review interface offers both inline (similar to unified) and side-by-side views. For comparing long documents with many small changes spread throughout, side-by-side view makes it easier to navigate and understand the overall scope of modifications.

Diff in Version Control

Git uses diff extensively: git diff shows unstaged changes, git diff --staged shows staged changes, and git diff <commit1> <commit2> shows changes between two commits. These diffs are the foundation of code review — reviewing what changed, not just the current state, is how developers verify that a commit does what it claims and does not introduce unintended side effects. Reviewers reading a diff can spot security vulnerabilities, logical errors, and style inconsistencies more easily than reading full files from scratch because the focused view of changes reduces cognitive load.

Three-way merge, used by git merge and git rebase, performs a diff between three versions: the common ancestor, the branch being merged, and the base branch. Changes made on each branch relative to the ancestor are applied to produce the merged result. Merge conflicts occur when both branches modified the same section differently — the diff algorithm cannot automatically determine which version is correct, and a developer must manually resolve the conflict by editing the file to combine both sets of changes correctly. Understanding how three-way merge works helps you structure commits to minimize conflicts when collaborating on shared codebases.

Diffing Non-Code Content

Diff tools are not limited to source code. Document management systems, content management platforms, and wiki software all use diff algorithms to track and display changes to articles and documentation. Comparing two versions of a legal contract, a technical specification, or a configuration file is straightforward with a text diff tool. For structured formats like JSON, XML, or YAML, semantic diff tools that understand the structure provide more meaningful comparisons than pure text diffs — they can identify that a JSON object had a key reordered versus actually changed, or that an XML element was moved versus modified.

Data comparison is another important application. When a database migration or data transformation changes a dataset, diffing a sample of rows before and after the transformation verifies that the changes match expectations. Exporting data to CSV or JSON and running a text diff catches unexpected changes that might otherwise go unnoticed. For binary files — compiled executables, images, audio files — specialized binary diff tools exist, though the output is typically less human-readable than text diffs and more useful for automated comparison than manual review.

Integrating Diff into Your Workflow

Making diff a habitual part of your development workflow improves code quality and reduces bugs. Before committing changes, always review the diff to confirm you are committing exactly what you intend — this catches accidental debug statements, leftover commented-out code, and files that were modified unintentionally. Before deploying to production, diffing the production branch against your deployment candidate gives you a concise summary of every change that will go live, making it easier to spot problems before they affect users. Configuring your text editor or IDE to show git diffs inline — which most modern editors support — makes this review seamless and immediate rather than a separate step.