Two versions,
one clear diff

Paste the original and the changed text to see every insertion and deletion marked line by line. Nothing is uploaded. Free, no sign-up required.

Original

0 lines

Changed

0 lines

Features

Everything you need to compare two versions of a document.

Split or inline

Read the two versions side by side, or as one stream of plus and minus lines like a patch file.

Ignore what does not matter

Turn off whitespace or case sensitivity when reindentation or a casing change is not the difference you are hunting.

Counts at a glance

Added, removed, and unchanged line counts sit above the result, so you know the size of a change before reading it.

Runs in your browser

Nothing is uploaded. Config files, contracts, and unreleased copy stay on your machine.

How to compare two texts

Three steps, and the result updates as you type.

Paste both versions

Original on the left, changed on the right. Either side can be empty if you are checking what a whole file adds.

Tune the comparison

Ignore whitespace when indentation changed, ignore case when only capitalisation moved. The diff updates immediately.

Read the result

Red lines were removed, green lines were added. Switch to inline view to read it as a single patch.

When you need this

Where a quick comparison saves the most time.

Checking what a config change did

Two versions of a YAML or .env file rarely differ where you expect. A diff shows the one line that actually moved.

Reviewing edited copy

When someone returns a document with no track changes, comparing the before and after is the fastest way to see their edits.

Comparing API responses

Paste two JSON payloads to find the field that changed between a working request and a failing one.

Finding an accidental change

A file that stopped working after an edit usually has one unintended difference. This narrows it down without a repository.

Understanding text diffs

What a diff algorithm is really computing, why line-level comparison is the useful default, and the two things that cause most confusing diffs: whitespace and line endings.

What a diff algorithm is actually solving

The obvious approach, comparing line one to line one and line two to line two, falls apart the moment a line is inserted. Everything after the insertion shifts by one position, so a one-line change reports the entire rest of the file as different.

What you want instead is the longest common subsequence: the longest ordered set of lines that appears in both versions, not necessarily contiguously. Lines in that sequence are unchanged. Everything in the old version that is not in it was removed, and everything in the new version that is not in it was added.

This is why a good diff of a file with one inserted line shows exactly one added line, no matter how much text follows it.

before        after         result
-----------   -----------   ------------
alpha         alpha         unchanged
beta          inserted      + inserted
gamma         beta          unchanged
              gamma         unchanged

The same idea drives git, code review tools, and the Unix diff command. They differ mainly in how they present the result and how they optimise the search.

Why the comparison is done on lines

Diffing character by character is possible and produces a technically smaller edit script, but it is much harder to read. A single-character difference in the middle of a paragraph would be reported as an edit deep inside a run of text, with no context around it.

Lines are the unit people actually reason about. Code is written in lines, configuration is written in lines, and prose breaks into lines and paragraphs. Reporting a change at line granularity matches how the text was authored.

The cost is that a one-word change reports the whole line as replaced. Some tools add a second character-level pass inside changed lines to highlight the specific words, which is a presentation layer on top of the same line-level result.

The whitespace problem

A large fraction of unhelpful diffs come from whitespace. Reindenting a block, switching tabs to spaces, or reformatting with a different tool changes every line in the region, burying the one real change in noise.

Ignoring whitespace during comparison solves the immediate problem, but it is worth knowing when not to. In languages where indentation is syntax, such as Python or YAML, an indentation change is a real change and hiding it is dangerous.

Trailing whitespace is a related nuisance. It is invisible on screen but counts as a difference, which is why a line can look identical on both sides and still be flagged.

The durable fix is to agree on formatting once, enforce it automatically, and keep formatting changes in commits of their own so they never mix with logic changes.

Line endings differ between platforms

Windows terminates lines with a carriage return followed by a line feed. Unix, Linux, and macOS use a line feed alone. A file that has travelled between the two can differ on every single line while looking identical in an editor.

This tool normalises carriage returns before comparing, so a file that only differs in line endings reports as unchanged. Version control systems usually handle it with a normalisation setting rather than by ignoring it, since the bytes genuinely are different.

If a diff shows every line as changed and you cannot see why, line endings are the first thing to check.

Diffs and merges are different problems

A diff compares two versions. A merge combines three: the two versions plus the common ancestor they both came from. That third input is what lets a merge tool tell "you added this line" apart from "they deleted it".

This is why a two-way comparison cannot resolve a conflict on its own. Given two files that differ, there is no way to know which side changed without knowing where they started.

For everyday work, a diff answers "what is different", and that is usually the question. When you need "how do I combine these", the answer lives in version control rather than in a comparison tool.

Common questions

What does a diff checker do?

It compares two blocks of text and reports which lines were added, which were removed, and which are unchanged. Rather than matching line one against line one, it finds the longest sequence of lines the two versions have in common, so inserting a line near the top does not make everything below it look changed.

Is my text uploaded anywhere?

No. The comparison runs entirely in your browser using JavaScript. Nothing you paste is transmitted, logged, or stored, which makes this safe for configuration files, contracts, and anything else you would not paste into a hosted service.

Why is a changed line shown as one removal and one addition?

This is a line-level diff, so a line is either the same or it is not. A modified line therefore appears twice: once in red as the old version and once in green as the new one. Reading them as a pair is how every line-based diff tool, including git, presents a change.

What does ignoring whitespace actually change?

It trims each line and collapses runs of spaces and tabs into one before comparing, so a line that was only reindented counts as unchanged. The original text is still displayed exactly as you pasted it; only the comparison is relaxed.

Can it handle large files?

Yes, within reason. Identical sections at the start and end are matched cheaply, so two large but similar documents compare quickly. Very large inputs that differ almost everywhere fall back to showing the old text as removed and the new text as added rather than attempting an expensive comparison.