Compare Texts

How does the comparison work?

Both texts are broken into lines and the difference comes out of the LCS (Longest Common Subsequence) algorithm. What stayed the same shows in gray, what was added in green and what was removed in red.

When comparing, only the whitespace at the start and end of each line is ignored. Uppercase, lowercase and punctuation all count.

It happens entirely in your browser, with no text sent anywhere.

When to compare texts: code review, contracts, documents, translations

Comparing two pieces of text is one of those tasks that looks trivial until you actually need to do it on documents that matter. Glancing at two paragraphs side by side and trying to spot what changed is exhausting and unreliable. A diff tool removes that cognitive load by mechanically aligning the two versions and highlighting only the parts that differ, so your eyes go straight to the meaningful edits instead of re-reading hundreds of identical lines.

In code review, diffing is the unit of conversation. Pull requests on GitHub, GitLab, Bitbucket and review systems like Gerrit or Phabricator all present changes as unified diffs. Reviewers can comment on specific added or removed lines, and the same format feeds linters, CI scripts and merge tools. Without a deterministic diff representation, asynchronous code review at scale would not exist.

In legal work, the same idea is called redlining. Lawyers compare drafts of contracts, NDAs, terms of service and statutes to know exactly which clauses changed between negotiation rounds. Microsoft Word's "Compare Documents" feature, Workshare Compare, Litera Compare and DraftAble all implement a diff specialised for legal prose. A missed change to a liability cap or a jurisdiction clause can cost millions, so the precision of an automatic comparison is not a nicety, it is risk control.

In translation and localisation, diffs identify what changed in the source text between releases so translators only retouch the affected segments instead of revisiting the whole file. Translation memory tools like Trados, memoQ and Smartcat rely on segment-level diffs, and CAT (computer-assisted translation) workflows often surface a side-by-side comparison so the reviewer sees both languages aligned.

In academic writing, journals frequently require authors to submit a "response to reviewers" with a tracked-changes version of the manuscript. In plagiarism detection, services compare student submissions against corpora to flag long verbatim matches. In data engineering, exporting two CSV files and diffing them is the cheapest way to verify that a migration script preserved the rows you expected. Comparing texts is, in short, a universal building block.

Algorithms: LCS, Myers (1986), Patience, Histogram

Every textual diff is ultimately a search for the Longest Common Subsequence (LCS) between the two inputs. The LCS is the longest sequence of elements that appears in both files in the same relative order, not necessarily contiguous. Once the LCS is known, everything outside it is either an addition (in the new file only) or a removal (in the old file only). The classic dynamic programming LCS runs in O(m * n) time and space, which is fine for two paragraphs but unacceptable for files with tens of thousands of lines.

The practical breakthrough was Eugene W. Myers' 1986 paper "An O(ND) Difference Algorithm and Its Variations", where N is the total length of the inputs and D is the size of the minimal edit script. For files that are largely similar, D is small and Myers runs almost linearly. This is the default algorithm used by GNU diff, by Git's --diff-algorithm=myers, by most language standard libraries, and by the JavaScript routine that powers this tool.

Myers produces the shortest edit script, but not always the most readable one. When code is refactored, Myers may align unrelated lines that happen to share whitespace or braces, producing a diff that humans struggle to follow. The Patience algorithm, introduced by Bram Cohen of BitTorrent fame and named after the card game, addresses this by first finding lines that appear exactly once in both files and anchoring them as alignment points, then recursing on the segments between anchors. The result is a diff that respects function boundaries and reads more naturally.

The Histogram algorithm, available in Git via --diff-algorithm=histogram, refines Patience by counting how often each line appears and preferring the rarest matches as anchors. It is generally faster than Patience and produces similar or better output, which is why many teams configure it as their default. Older algorithms include Hunt-McIlroy (1976), which pioneered the k-candidates technique at Bell Labs and inspired the original Unix diff command, and Wagner-Fischer for edit distance at the character level.

Unified diff format: +/- lines, context, @@ header

The unified diff format, introduced by GNU diff in 1990 and adopted by Git, is the lingua franca for representing textual changes. A unified diff is plain text that can be emailed, pasted into a ticket, applied with patch -p1 or visualised in any review tool. A short example:

diff --git a/greet.py b/greet.py
index 5be4a4a..0123456 100644
--- a/greet.py
+++ b/greet.py
@@ -1,5 +1,6 @@
 def greet(name):
-    return "Hello " + name
+    if not name:
+        return "Hello stranger"
+    return f"Hello {name}"

 print(greet("Ada"))

The header --- a/greet.py and +++ b/greet.py name the old and new files. The hunk header @@ -1,5 +1,6 @@ means "starting at line 1, five lines of the old file map to six lines of the new file". Lines beginning with a space are context (unchanged, shown for orientation), lines with - were removed, and lines with + were added. The default is three lines of context above and below each change, configurable with -U.

A special line \ No newline at end of file appears when one of the versions lacks a terminating newline. Hunks may optionally show the enclosing function name after the second @@, which is what lets you read a Git diff and immediately know which function changed without scrolling.

Line vs word vs character comparison

The same algorithms can operate on different tokens, and the choice profoundly changes the result.

• Line-level diff is the default for source code. Each line is a token. Fast, easy to read, but a one-character fix to a long line shows the whole line as removed and re-added.
• Word-level diff tokenises on whitespace and punctuation. Ideal for prose and translations because it highlights only the words that actually changed inside otherwise identical sentences. Git supports it with git diff --word-diff.
• Character-level diff compares one character at a time. Useful for short strings, identifiers, or to show typos and case changes. Cost grows quadratically, so it is impractical for full documents.
• Semantic diff tools like difftastic parse the file into a syntax tree and diff nodes, ignoring formatting noise like reflowed lines or moved braces.

Desktop and GUI tools

Beyond the command line, mature graphical comparison tools have served developers, writers and engineers for decades:

• diff (Unix, GNU diffutils) — the original, still bundled with every POSIX system.
• Beyond Compare (Scooter Software, paid, Windows/macOS/Linux) — compares text, folders, PDFs, Word documents, images and tables; three-way merge.
• Meld (free, open source, GNOME) — two and three-way file and folder comparison with VCS integration.
• WinMerge (free, open source, Windows) — long-standing Windows favourite with syntax highlighting and folder sync.
• Kaleidoscope (paid, macOS) — polished interface, image and text diff, integrates with Git, SVN and many editors.
• VS Code — built-in side-by-side diff, accessible via code --diff a.txt b.txt, plus rich diff view inside the SCM panel.
• P4Merge, Araxis Merge, DiffMerge, ExamDiff Pro — additional commercial and free options.

Legal scenarios: contract amendments and redlining

In contract negotiation, every revision counts. A diff tool tells the paralegal exactly which clauses the counterparty changed, whether a number was nudged, whether a definition was tightened or relaxed, whether a "shall" became a "may". Microsoft Word's "Compare Documents" produces a redlined version with inserts, deletes and reformatted text marked up; specialised tools like Litera Compare, Workshare Compare and DraftAble are tuned for legal prose, ignoring trivial formatting differences and producing reports that lawyers can sign off on.

Beyond contracts, legal applications include comparing statutes between editions, tracking amendments to corporate bylaws, verifying that a translated treaty matches the original, and proving authenticity in litigation. Some jurisdictions accept a printed redline as evidence of a change, which means the diff itself becomes part of the case file.

Limits: binary files and semantic vs textual changes

Textual diff tools assume the inputs are plain text. They fail on binary files like images, compiled executables, ZIP archives, Word documents (which are zipped XML internally) and PDFs. Git detects binary content and prints Binary files differ instead of a diff. For binaries you need a format-aware tool: ImageMagick for images, pandoc to convert Office documents to plain text before diffing, or specialised products like Beyond Compare and Diffchecker which include PDF and image modes.

A second limit is semantic blindness. A textual diff sees characters, not meaning. Renaming a variable from x to total across a function appears as many added and removed lines even though the logic is identical. Reformatting a JSON file with different indentation produces a huge diff that contains no behavioural change. Conversely, a one-character bug like >= turned into > looks tiny in the diff but can break production. Reviewers must always understand that diff size is not a proxy for risk.

FAQ

Is anything sent to a server?

No. This comparator runs entirely in your browser using JavaScript. The texts you paste never leave the page, which makes it safe for confidential contracts, internal source code or unreleased manuscripts.

Which algorithm does this tool use?

A line-level comparison based on the Longest Common Subsequence, equivalent to the default Myers behaviour. Lines unchanged are kept, additions are marked with + and removals with -, matching unified diff conventions.

Can I compare more than two files at once?

This tool handles two inputs. For three-way merges, where you compare a common ancestor with two divergent versions, use Git itself or desktop tools like Meld, Beyond Compare or KDiff3.

How do I ignore whitespace differences?

For now, normalise the inputs yourself (trim trailing spaces, unify indentation). On the command line, git diff -w ignores all whitespace, and diff -b ignores blank changes.

Why does my refactor produce a confusing diff?

Because Myers minimises edits without understanding structure. For large refactors, try a Patience or Histogram diff in Git (git diff --histogram) or a syntax-aware tool like difftastic.