Free Text Diff & Merge

How to Use

1. Paste two texts. Original on the left, revised on the right. Anything that lives as plain text (code, configuration files, prose, JSON, contracts) works.
2. Click Compare. Changed lines are highlighted, green for additions, red for deletions, with character-level highlighting inside changed lines.
3. Review and copy. Scroll through the diff, screenshot the section you need, or copy a specific change. Use Swap A↔B to flip the comparison direction.

A Short History of Diff

Modern text diffing began at Bell Labs. Douglas McIlroy (the same McIlroy who invented Unix pipes) and James W. Hunt wrote the original Unix diff in the early 1970s; it shipped as part of the 5th Edition of Unix in 1974. The algorithm was documented in Bell Laboratories Computing Science Technical Report #41 (June 1976), an internal report titled "An Algorithm for Differential File Comparison." The Hunt-McIlroy algorithm is built on the longest common subsequence (LCS) problem, find the longest sequence of lines that appears, in order, in both inputs, and everything not in that sequence is either a deletion or an insertion. A decade later, Eugene W. Myers published "An O(ND) Difference Algorithm and Its Variations" in Algorithmica, Vol 1 Issue 2 (1986). Myers reframed the problem as shortest-path finding over an "edit graph" and showed it could be solved in O(ND) time and space, where N is the input size and D is the size of the minimal edit script. For typical inputs (files that differ in only a few places) D is small, so the algorithm is fast in practice. Myers's paper became the basis for a faster Unix diff implementation that ran two to four times faster than its predecessor and produced higher-quality output. Patience diff (Bram Cohen, 2008) is an LCS refinement that prioritises unique anchor lines, producing more readable diffs around moved blocks. The current default in git diff is the histogram algorithm in LibXDiff, generally regarded as faster than vanilla Myers and producing more readable diffs in the presence of moved blocks (it became Git's default in 2.11, released 29 November 2016). The mathematical foundations go even deeper: the Levenshtein distance (Vladimir Levenshtein, 1965) is the LCS problem's character-level cousin, and the Wagner-Fischer dynamic programming solution (1974) is what every "fuzzy match" library still implements internally.

How a Diff Is Rendered

There are four common visual conventions for displaying a diff. Side-by-side: two columns, original on the left, modified on the right, with corresponding lines aligned. Good for at-a-glance comparison; works well at desktop widths but becomes unreadable on narrow mobile viewports. Inline unified diff: a single column showing removed lines (typically prefixed with - and coloured red), added lines (+, green), and unchanged context lines (no prefix, plain text). The layout git diff uses by default. Scales well to mobile but loses the spatial parallelism of side-by-side. Word-level diff: highlighting only the words that changed within changed lines. Useful for prose comparison where most of the text is unchanged but specific phrases were edited. Character-level diff: highlighting every changed character individually. Useful for very small changes (a typo correction, a single-digit edit) where word-level would highlight the entire word. Colour conventions are remarkably consistent across the ecosystem: green for additions, red for removals, yellow or amber for changed values, neutral grey or unstyled for unchanged. This tool uses the inline unified style with character-level highlighting inside changed lines, a hybrid that scales well to mobile while preserving the precision of character-level comparison for prose edits.

Three-Way Merge, When Two Diffs Need to Combine

A two-way diff (this tool) tells you what changed between version A and version B. A three-way merge answers a harder question: given a common ancestor and two divergent revisions, what's the combined result that incorporates both sets of changes? This is the core operation of every version control system, when two developers edit the same file independently and one tries to merge their work, the system needs to apply both diffs to the original. The diff3 algorithm formalised by Khanna, Kunal and Pierce (2007) is the basis. The seven-character conflict marker convention, <<<<<<<, =======, >>>>>>>: that Git inserts into files when an automated merge fails comes directly from this lineage. Modern visual merge tools (VS Code's three-pane merge editor, default-on since 1.69 in June 2022; Beyond Compare from Scooter Software, since 1996; Meld; Kaleidoscope by Black Pixel for macOS) handle three-way merges with side-by-side rendering of all three versions plus a fourth pane for the proposed merge result. This tool focuses on two-way comparison, three-way merging belongs in a real version control workflow.

Common Use Cases

• Code review. Pasting two versions of a function or module to spot the change quickly, especially when working outside a Git workflow (a snippet from a colleague's email, a Stack Overflow answer vs your current code).
• Legal contract comparison. Lawyers and contract negotiators routinely compare two versions of a contract to see what the other side changed. The legal-tech term is "blackline" or "redline" comparison; products like Draftable specialise in this.
• Prose editing. Comparing a writer's draft against an editor's revision, or two versions of an article. Microsoft Word's Track Changes does this in-product; for plain-text or Markdown drafts, a diff tool is the equivalent.
• Configuration drift. Comparing a config file in production against the version in source control, the gap is the drift. Same workflow for environment-specific configs (dev vs staging vs production).
• Log comparison. Diffing two log files from different runs of the same process to find the divergence point.
• Localisation review. Translators frequently diff a new English source against the previous version to identify exactly what's new and needs translating.

The Diff Ecosystem in 2026

Beyond git diff and Unix diff, several specialised diff tools deserve mention. Beyond Compare (Scooter Software, 1996) is the long-standing commercial folder-and-file comparison tool, popular with developers and IT professionals for cross-machine diffing. Meld (open source, GTK-based) is the GNOME default. Kaleidoscope (Black Pixel, macOS) integrates with version control and is the de facto choice for many Mac developers. VS Code's built-in diff editor handles two-way and three-way comparisons natively; the three-pane merge editor became default-on in 1.69 (June 2022). Mergely (Wayne Stidolph, 2013, MIT-licensed) is the canonical browser-based two-way merge editor built on CodeMirror. jsdiff (Kevin Decker, ~2010) is the dominant JavaScript diff library, used by every browser-based diff tool you've ever pasted into. diff-match-patch (Neil Fraser at Google, 2006) is the alternative library that handles diffing, fuzzy matching and patch generation in a single API; used in Google Docs revision history. Diffchecker is the dominant freemium online diff service, full-featured but with privacy paywalled (the free tier sends text to their server). text-compare.com is the longest-running pure-text web diff site, dated UI but functional.

Privacy: Why Browser-Only Matters Especially Here

Every diff reveals exactly what changed between two versions, and what changed is often more sensitive than either version alone. Three concrete scenarios where this matters acutely. Security patches: diffing a vulnerable version of a function against the patched version reveals the precise location and nature of a security bug, an attacker who finds the patch can craft an exploit for the unpatched version (the "patch gap" attack documented by Tian et al. at USENIX Security 2017). Pasting a security patch into a server-side diff tool is essentially publishing the vulnerability. Contract negotiation: diffing two versions of a contract reveals exactly which clauses each side cares about, which is precisely the information you don't want the other side (or anyone watching the network) to have during negotiation. Pre-publication editorial decisions: diffing a manuscript before and after editing reveals what an author and editor decided to cut or change, often more revealing than the final published version. Server-side diff tools upload both versions to a third party, where they sit in logs. This tool runs entirely in your browser via JavaScript, verify in DevTools' Network tab while you click Compare, or take the page offline (airplane mode) after it loads and the tool still works.

Frequently Asked Questions

Can I compare code files?

Yes. The diff is purely text-based, so any plain-text format works, JavaScript, Python, Go, Rust, JSON, YAML, HTML, Markdown, configuration files, log entries. There's no syntax highlighting (a syntax-highlighting diff would need a per-language parser) but the line-by-line comparison is identical to what git diff would produce. For code-specific workflows with syntax highlighting and three-way merge, use VS Code's built-in diff editor or a dedicated tool like Beyond Compare.

Does it ignore whitespace differences?

Toggle the "Ignore whitespace" option to skip differences that are only spaces, tabs, or line endings. Useful when comparing code that was reformatted (Prettier ran, or a tabs-vs-spaces conversion happened) but not meaningfully changed. Without the option, every whitespace difference is reported as a real change. git diff -w does the same thing.

What algorithm does this use?

Myers's O(ND) algorithm (Eugene Myers, Algorithmica Vol 1 No 2, 1986), the same algorithm GNU diff used by default for decades and the basis for most text-diff implementations. Myers reframed the longest-common-subsequence problem as shortest-path finding over an edit graph, making it fast in practice for inputs that differ in only a few places. The newer histogram algorithm (Git's current default since v2.11, November 2016) handles moved blocks slightly better but is overkill for the typical two-paste use case this tool handles.

Is there a size limit?

No hard limit, but the comparison runs in your browser via JavaScript so the practical ceiling is your device's available memory. Tens of thousands of lines work comfortably. Very large inputs (multi-megabyte log files, full novels) will run but may take noticeable seconds to render. For genuinely huge inputs use Git's diff on the command line, it streams output and handles arbitrary-size files without memory pressure.

Can it do three-way merge or apply patches?

Not currently, this tool focuses on two-way comparison (A vs B). Three-way merge (the diff3 algorithm with conflict markers <<<<<<< / ======= / >>>>>>>) is the operation Git uses when merging branches; it requires a common ancestor plus two divergent versions. For three-way merge, use a real version control system or a dedicated tool like VS Code's three-pane merge editor (default-on since 1.69 in June 2022).

Are my texts uploaded?

No. Comparison runs entirely in your browser via JavaScript. The texts you paste never cross the network, verify in DevTools' Network tab while you click Compare, or take the page offline (airplane mode) after it loads and the tool still works. Especially safe for diffing security patches (where the diff itself reveals the vulnerability), contract revisions (where the diff reveals negotiation positions), or pre-publication editorial drafts.