Paste two texts. See every change highlighted line by line.
Compare two pieces of text side by side and see exactly what changed — added lines, removed lines, modified words. Useful for code review, version comparison, contract redlining, and anywhere two versions of "the same" text need to reconcile. Everything runs locally in your browser; nothing is uploaded.
A diff between two pieces of text answers the question: "what would I have to do to turn version A into version B?" The answer is a list of insertions, deletions, and (optionally) modifications. Lines present in A but not B are deletions; lines in B but not A are additions; lines that appear in both are unchanged. Modified lines are shown either as a paired delete-and-add, or as a within-line word diff highlighting just the changed parts.
The diff algorithm matters. Naive line-by-line comparison fails when lines are inserted in the middle — every line after the insertion point shows as different. Real diff tools use the Myers algorithm or its variants, which find the longest common subsequence and produce a minimal edit script. This tool uses the Myers algorithm, which is the industry standard.
Code review. The original use case for diff tools. Compare an old version of a file against a new version to see what changed before approving a pull request. Most code review platforms (GitHub, GitLab, Bitbucket) build their interfaces on top of diff output.
Comparing two versions of a document. A contract draft from a counterparty against your version, or a blog post draft before and after editing, or a configuration file before and after a deployment. Anywhere "what changed?" is the question, diff is the answer.
Verifying a copy operation. You exported data from one system, imported into another, exported back out. Diff the original export against the round-tripped version to confirm nothing was lost in translation.
Spotting unauthorized changes. Compare a known-good version of a file against the current state to catch tampering. Useful for config files, security policies, and compliance audits.
Translation review. Compare an old translation against a new translation to see what the translator changed. The English-original side stays constant; the translated side shows the evolution.
Comparing API responses across environments. The same API call against staging vs production sometimes returns subtly different data. Pretty-print both responses (use the JSON Formatter), then diff them to find the differences.
Editor's redline. Writers and editors compare draft versions to track which suggestions were accepted, rejected, or modified. Diff is the technical underlay of "track changes" in word processors.
Email and proposal version control. Comparing two drafts of an important email to see exactly what got softened or tightened.
Two granularities, two different views.
Line-level diff treats each line as a unit. If anything changes on a line — even a single character — the entire line is shown as removed and a new version added. This is what GitHub, GitLab, and most version control diff displays use. It's the right granularity for code, where lines are usually meaningful units.
Word-level diff highlights exactly which words within a line changed, with the unchanged surrounding context kept in place. This is the right granularity for prose — when you change "happy" to "joyful" in a paragraph, word-level diff shows just that swap, not the whole paragraph as removed-and-readded.
This tool defaults to line-level for most uses but offers word-level highlighting on lines that are similar enough to suggest they're the same line modified.
Whitespace changes producing big diffs. Indentation changes, trailing whitespace, and Windows-vs-Unix line endings can make two functionally identical files look completely different. The tool offers a "ignore whitespace" option that normalizes whitespace before comparing — use it when whitespace isn't meaningful.
Smart quotes vs straight quotes. Pasting from Word or Google Docs converts straight quotes to curly. If your "old" version has straight quotes and "new" has smart quotes, diff shows every quote as changed. Either normalize quotes before comparing, or accept that the diff will be noisy.
Line ending mismatches. A file saved on Windows (CRLF line endings) compared against the same file saved on Unix (LF) shows every single line as different in tools that don't normalize. This tool normalizes line endings before comparing — both sides are converted to LF.
Reordered content with no actual changes. If two files contain the same paragraphs but in different order, line diff shows it as if everything was deleted and reinserted. Diff tools can't tell you "you reordered these" — they just see deletes and adds. For reorderings, sort both inputs first and diff the sorted versions to confirm they contain the same content.
Binary files. Diff is for text. Pasting binary data (PDFs, images, etc.) produces nonsensical output. If you need to compare binary files, use a binary diff tool like cmp or xxd | diff.
This tool — fastest for ad-hoc text comparison, no install, runs locally. Best for "I have these two strings, what's different?"
Git diff — diff between commits in a Git repository. The same Myers algorithm; the difference is workflow. Use Git diff when the two versions are commits in the same repo. Use this tool when they're loose strings.
Microsoft Word's "Compare Documents" (Review → Compare) — produces a redlined output as a third document. Best when both versions are .docx files and you need to see the result with proper change tracking, comments, and author attribution. This tool produces inline diff display; Word produces a deliverable redline document.
diff command — the Unix utility. Same algorithm; different output formats (unified, context, side-by-side). For automation and pipelines, diff command beats GUI tools.
Paste version A on one side, version B on the other. The tool runs the Myers diff algorithm to find the longest common subsequence, then produces an edit script — the sequence of insertions and deletions that transforms A into B. Output is rendered side by side or as a unified diff, depending on the display mode you select.
For very large inputs (over a few hundred thousand lines), the algorithm becomes slow because it's O(N·D) where D is the number of differences. Most real-world diffs have D much smaller than N, so performance is acceptable. Pathological cases (two completely unrelated files of similar size) can be slow.
Diff smaller chunks for clarity. A 5,000-line diff is overwhelming. If you're comparing large files, diff section by section — function by function for code, chapter by chapter for prose. The same algorithm, but the output is reviewable.
Normalize before diffing. If you know whitespace, line endings, or quotes will differ, normalize both sides through Remove Spaces or a similar tool before comparing. The diff output is then about meaningful differences only.
For prose, prefer word-level diff. "I changed this sentence to that sentence" reads better as inline word swaps than as deleted line plus added line. Switch display modes when reviewing prose.
It uses the Myers algorithm, which finds the minimal edit script. If two files share most content, the diff shows just the changes; if they're completely different, the diff shows everything changed. Quality scales with how related the inputs are.
Up to a few hundred thousand lines is comfortable. Beyond that, browser memory and algorithm complexity become limiting. For huge files, use the command-line diff tool instead.
Yes. The "ignore whitespace" option normalizes both inputs (collapses runs of whitespace to single spaces, trims line endings) before comparing. Use it when whitespace isn't meaningful.
Currently, comparison is case-sensitive. To do a case-insensitive diff, paste both inputs through the Case Converter set to lowercase before comparing.
The Myers algorithm produces minimal edit scripts, not "intuitive" ones. Sometimes the algorithm finds an unexpected match between distant lines that produces a smaller total diff but a less readable one. This is correct behavior; if it's confusing, edit one side to make the differences cleaner before comparing.
No. The diff is computed entirely in your browser. Both inputs and the output exist only in your browser session. Refresh the page and everything is gone.