Text Diff / Compare

This tool compares two blocks of text line by line and shows the result as one combined listing: unchanged lines in the normal colour, lines that exist only in the original in red with a strike-through, and lines that exist only in the modified text in green. The comparison runs on every keystroke, so you can paste both sides and immediately see what moved. It is built on the jsdiff library, a package used widely in JavaScript tooling to print assertion and file differences, using its line-level comparison.

Two properties of the output are worth knowing up front. First, the tool has no concept of a "changed" line: an edited line appears as the old line removed followed by the new line added. Second, the unit of comparison is the whole line including its line break, so a difference in indentation, trailing spaces or line endings makes a line count as different even when the visible words match.

How a diff is computed

A diff tool looks for the longest sequence of lines that both texts share in the same order, then reports everything outside that sequence as removed or added. The classic way to find it is Myers' algorithm from 1986, which searches for the shortest edit script and runs in time proportional to the text length multiplied by the number of differences. That is why comparing two long texts that are mostly the same is fast, while comparing two long texts that are almost entirely different is slow. Git uses the same family of algorithm by default and offers alternatives (patience, histogram) that often produce more readable output when blocks of code move.

Because several edit scripts can be equally short, the algorithm sometimes pairs lines in a way that looks odd to a human, for instance matching a closing brace from the wrong block. That is a limitation of every line diff, not a bug in this page. Moved blocks are always shown as a removal in one place and an addition in another; no line diff detects moves. For more depth, read the guide on how text diff algorithms work.

Whitespace and line endings cause most surprises

• CRLF versus LF. A file saved on Windows ends each line with a carriage return plus a line feed, a file saved on Linux or macOS with a line feed alone. To a line diff every single line differs, so the whole text lights up red and green. Convert both sides to the same ending first (most editors have a line-ending switch in the status bar, and dos2unix does it on the command line).
• The last line. If one side ends with a newline and the other does not, the final line is reported as removed and added even though the text is identical. Command-line diff prints "No newline at end of file" for the same situation.
• Indentation and trailing spaces. Tabs versus spaces, a reindented block, or spaces left at the end of a line all count as changes here. This page has no ignore-whitespace switch, so normalise the text before pasting, or use the command-line flags below.
• Invisible characters. Non-breaking spaces copied from a web page, smart quotes pasted from a word processor, and a byte order mark at the start of a file all look identical on screen and different to the algorithm.

Reading unified diff output elsewhere

This page shows an inline view, but git, code review tools and diff -u emit the unified format. Two header lines name the files (--- for the old, +++ for the new). Each change block starts with a hunk header such as @@ -12,4 +12,6 @@, meaning the hunk covers 4 lines starting at line 12 in the old file and 6 lines starting at line 12 in the new one. Lines prefixed with a space are context (three lines by default), - lines were removed and + lines were added. Patches made this way can be applied with git apply or patch -p1.

Command-line equivalents

diff -u old.txt new.txt              # unified diff, three lines of context
diff -w old.txt new.txt              # ignore all whitespace differences
diff -B --strip-trailing-cr a b      # ignore blank lines and CRLF endings
diff -y old.txt new.txt              # side-by-side view
git diff --no-index old.txt new.txt  # git's diff engine outside a repository
git diff -w --word-diff              # ignore whitespace, highlight changed words
git diff --diff-algorithm=patience   # often cleaner when blocks move
fc /n old.txt new.txt                # Windows command prompt
Compare-Object (Get-Content old.txt) (Get-Content new.txt)   # PowerShell

Editors do this well too: VS Code has "Compare Active File With" in the command palette, and code --diff old.txt new.txt opens the same view from a terminal.

When a line diff is the wrong tool

For JSON or YAML, formatting and key order create noise that hides real changes; the JSON Diff tool compares the parsed structure instead. Run both sides through the File Formatter first if you must diff them as text. For prose, a word-level diff (git diff --word-diff or wdiff) is easier to read than whole paragraphs marked as replaced.

Privacy

Both texts stay in your browser. The diff is computed in page memory and nothing is sent to a server, so contracts, internal emails and unreleased code can be compared safely.

1. Paste the original version into the left box (Original Text).
2. Paste the new version into the right box (Modified Text).
3. The result panel updates as you type: unchanged lines stay plain, removed lines are red with a strike-through, added lines are green.
4. If the whole text lights up, check for CRLF versus LF line endings or a reindented block before reading the details.

• Reviewing edits to marketing copy or documentation without emailing tracked-changes documents around.
• Comparing an .env or config file from staging against production to find the one setting that differs.
• Spotting what changed between two runs of a script by pasting both outputs.
• Checking a generated file (a lockfile, a schema dump, an OpenAPI export) against the version committed in git.
• Finding the unintended whitespace-only changes an editor introduced before you commit.