Text Diff — Compare Two Texts Online

What a text diff is for

A diff is a compact description of how two pieces of text differ. Give the tool two inputs — a "before" and an "after" — and it tells you which lines are the same, which were removed, which were added, and (as a nice side effect) which lines stayed exactly where they were. This is the foundation of every version control system, every code review, every document collaboration tool, and a handful of non-obvious debugging workflows.

This tool does line-based diff in your browser. No login, no upload, no server round-trip — paste two blocks of text and see the differences instantly. Works on code, config files, prose, markdown, CSV, logs, or anything else with a meaningful line structure.

When you reach for a text diff

• Code review without a PR. A coworker pasted two versions of a function in Slack and you need to spot the change. Paste both sides, read the diff in 5 seconds instead of comparing them line-by-line with your eyes
• Config drift. Your staging config.yamldiffers from prod and you're trying to figure out which env variable is missing. Diff the two
• Production incident forensics. The log format changed between two deployments — diff a known-good log entry against a broken one to find the structural difference
• Prose editing. An editor sent back a marked-up version of your draft. Diff the two versions to audit exactly what they changed instead of re-reading the whole article
• Legal document comparison.Contract v3 vs v4. Paste both, see what shifted. Important: this tool is a line diff, not a semantic legal diff — but for spotting clause-level changes it's faster than track-changes
• API response regression. An endpoint started returning different data after a deploy. Capture the old and new response, diff them, find the field that changed
• Migration verification. You migrated a database and want to confirm two tables have identical rows. Export both as CSV, diff them

How line diff actually works

The algorithm behind this tool is the longest common subsequence (LCS) method, a classic dynamic-programming approach taught in every algorithms course. It finds the longest sequence of lines that appears in both inputs, in order, then identifies every other line as either deleted (only in the original) or added (only in the modified). The math is O(m × n) in time and space where m and n are the line counts — plenty fast for any real-world text up to ~5,000 lines per side.

Some tools use Myers's diff algorithm (what Git uses by default) which is faster on large inputs and produces slightly more intuitive diffs in some edge cases. For the sizes people actually paste into a browser tool, the two produce identical output 99% of the time. We went with LCS because it's 60 lines of code, has no external dependency, and is easy to understand if you want to read the source.

How to use this tool

1. Paste the original text into the left box (A)
2. Paste the modified text into the right box (B)
3. The diff renders instantly below. Green lines are additions (only in B), red lines are deletions (only in A), and unchanged lines show in normal style
4. Toggle between side-by-side view (default — easier for reviewing changes in context) and unified view (classic diff format with +, -,   prefixes — easier to copy into a commit message or a bug report)
5. Click Swap A ↔ B to flip the two inputs — useful when you realize you pasted them in the wrong order
6. Toggle Ignore whitespaceif you want to treat runs of spaces/tabs as equivalent — catches the "it looks the same but the indentation is off" case
7. Click Copy unified diffto put the patch-style output on your clipboard — it's the format GitHub, Git, and every code-review tool understands
8. The stats row at the top shows X added, Y removed, Z unchanged so you know the scale of the change at a glance

Reading a unified diff

The unified format looks like this:

  function greet(name) {
-   console.log("Hello, " + name);
+   if (!name) name = "stranger";
+   console.log(`Hello, ${name}!`);
  }

  greet("world");
+ greet();

Each line is prefixed:

•    (two spaces) — unchanged line, present in both A and B
• - (minus + space) — line removed, present in A only
• + (plus + space) — line added, present in B only

This is the same format used by git diff, patch files, GitHub pull requests, and every code review tool built in the past 30 years. If you copy the output and paste it into a GitHub issue or Slack thread, your readers will know how to read it.

Side-by-side vs unified — when to use which

• Side-by-side: best for review— reading to understand what changed. Your eye tracks naturally between the two columns. Good for prose, configuration, and code you're seeing for the first time
• Unified: best for communication— copying a diff into a bug report, a commit message, or a Slack thread. Also what tools expect if you're piping the output somewhere else. More compact than side-by-side because unchanged lines don't take twice the horizontal space

What this tool does not do

• Character-level or word-level diff within a line. When a single line is edited slightly ("hello" → "hallo"), this tool shows the whole line as both deleted and added. Tools like VS Code's diff viewer and GitHub's PR view highlight the specific characters inside a changed line; that's a nice-to-have we might add later
• Semantic diff. We compare lines literally. Two JSON objects that are equivalent but have their keys in different order will show as different here. For structured-data comparison, use the JSON Diff tool which parses both inputs and diffs the parsed trees
• Binary files. This is a text tool. Images, PDFs, and compiled binaries need different tools entirely
• Merge conflict resolution. A diff shows you differences; resolving them is a separate editing step. Use your IDE or git mergetool
• 3-way diff. We compare two texts at a time, not three (common ancestor + two branches). For that, use a proper merge tool

Common pitfalls

• Line ending mismatch. If A uses Unix \n and B uses Windows \r\n, the diff can show every single line as changed because each line has a trailing \r character. Paste the text from a source that uses consistent line endings, or normalize before comparing
• Trailing whitespace changes.A line with a trailing space differs from the same line without one. Use the "Ignore whitespace" toggle to get rid of this noise
• Tab vs space indentation.Visually identical, literally different. The tool sees them as different. "Ignore whitespace" collapses runs of space or tab characters into single spaces
• Copy-paste autocorrect.Some editors and chat apps autocorrect "straight quotes" (U+0022) into "curly quotes" (U+201C / U+201D). If you paste the same text from two sources and the diff shows them as different, check for smart-quote replacement. It's the most common diff ghost bug
• Non-printing characters. Zero-width spaces (U+200B), BOM (U+FEFF), and other invisible characters can cause lines that look identical to diff as different. If you suspect this, paste the suspect text into a hex viewer first

Privacy

The diff runs entirely in your browser using a pure-JS implementation of the LCS algorithm. No network call is made, no analytics is collected on the text you compare, nothing is logged. Safe for private legal documents, internal source code, unreleased content, and sensitive configuration. Close the tab and everything is gone.

Frequently asked questions

How big a text can I diff?

The LCS algorithm is O(m × n) in both time and memory, so ~5,000 lines per side is a comfortable ceiling on a modern laptop. Above that it starts feeling sluggish; above ~20,000 lines you'll hit memory pressure. For comparing huge files, use diff on the command line.

Does this work offline?

Once the page loads, yes. The diff algorithm is bundled with the page — no runtime network calls are made. You can disconnect and keep diffing.

Can I diff JSON with this tool?

You can, but for JSON specifically the JSON Diff tool is better. It parses both inputs and diffs the resulting object trees, so key order and formatting don't create false differences. This tool is for text where line structure is meaningful (code, config, prose, logs).

Why are my identical lines showing as different?

Almost always one of three things: different line endings (CRLF vs LF), trailing whitespace on one side, or invisible Unicode characters (curly quotes, BOM, zero-width spaces). Turn on "Ignore whitespace" to rule out the first two. For the third, paste the text into a hex-aware viewer.

Why is there no word-level highlighting?

V1 of this tool does line-level diff only. Word-level highlighting inside changed lines is more complex and requires a second pass (diff on the characters within paired delete/insert lines). It's a reasonable future addition; for now, the line-level view is enough for most real-world use cases.

Is this a replacement for git diff?

No — it's for the cases where git diffis overkill or unavailable. You do not have a git repo, you do not want to make a commit just to compare, you want to show a teammate a diff in a chat. Those are this tool's use cases. For version-controlled code review, use git.

Is my data sent anywhere?

No. The LCS algorithm runs in your browser, the diff output is rendered in your browser, and nothing is transmitted anywhere. No analytics is collected on the content you paste.