Is my text uploaded anywhere?

No. The comparison runs entirely in your browser using the same diff algorithm as popular command-line tools; nothing is sent to a server.

What does the unified diff format mean?

Lines starting with - were removed, lines starting with + were added, and unmarked lines are unchanged context shown to help locate the change. It's the same format produced by `diff -u` and used in patch files.

Does this compare word by word instead of line by line?

No — this tool diffs whole lines, which is the standard approach for comparing config files, logs and code. For a single sentence edited in place, a word-level diff would show less noise, but line diffs are far more common for real files.

Why do unchanged lines still appear in the output?

A few lines of surrounding context (3 by default) make it much easier to see where in the file a change happened, rather than showing added/removed lines with no anchor.

Text Diff Checker

Compare two blocks of text line by line and get a unified diff plus added/removed line counts. Nothing is uploaded — the comparison runs in your browser.

Loading tool…

Worked examples

A changed line and an added line
The everyday case: one line edited and one line appended, shown as a standard unified diff with a single hunk.
Two identical blocks of text
Confirms two pasted blocks are byte-for-byte identical — a quick sanity check before assuming a deploy or config change actually did something.
A removed line and an appended line
A line removed from the middle and a line added at the end — the diff keeps unrelated context lines so the change is easy to locate.

What this tool does

This tool compares two blocks of text and shows a unified diff — the same format produced by diff -u and used in patch files — along with a count of lines added, removed and left unchanged. Everything runs in your browser from the two blocks you paste in; nothing is uploaded.

When you need it

Reviewing a change to a config file, log excerpt or piece of prose before committing to it, without opening a full version control diff view.
Confirming that two versions of a document — an email draft, a contract clause, a generated report — are identical or spotting exactly where they diverge.
Comparing output from two runs of a script or command to see what changed between them.
Checking a copy-pasted block of text against the original source to catch accidental edits introduced while moving it between tools.

Reading the unified diff

Each line in the output starts with one of three markers. A line beginning with - was present in the "before" text and removed. A line beginning with + is new in the "after" text. An unmarked line is unchanged context, shown around each change so you can see where in the file it happened rather than a change floating with no anchor. Lines are grouped into hunks, each headed by a line like @@ -1,3 +1,4 @@ that records the line ranges affected on each side — useful when applying the diff as an actual patch, but safe to ignore if you're just reading the comparison visually.

Why line-by-line, not word-by-word

This tool diffs whole lines rather than individual words or characters. That's the standard approach for comparing structured text — config files, source code, log output, line-delimited data — where a change to one line shouldn't be conflated with changes to its neighbors. If you're comparing a single sentence or paragraph edited in place, a line diff will show the entire line as removed-and-re-added even for a one-word change; that's expected behavior for this kind of comparison, not a bug. For that narrower case, a word-level diff would show less noise, but line diffs are far more useful for the majority of real files people compare.

Reading the counts

The added and removed counts reflect total lines, not total hunks — a single hunk that replaces three lines with four shows as three removed and four added, even though it reads as "one change" visually. The unchanged count is the total number of lines that are identical in both inputs, across the whole text, including lines too far from any change to appear as context in the diff. Line endings count as content: a file saved with Windows (CRLF) endings compared against the same text with Unix (LF) endings shows every line as changed, and a missing newline at the end of the file is flagged with a "No newline at end of file" marker.

Limits

Each side is capped at 2 MB of text, comfortably larger than any file you'd want to review by eye in a browser tab. For genuinely large files, a dedicated command-line diff tool with pagination will be more practical than a browser-based comparison.

Frequently asked questions

Is my text uploaded anywhere?: No. The comparison runs entirely in your browser using the same diff algorithm as popular command-line tools; nothing is sent to a server.
What does the unified diff format mean?: Lines starting with - were removed, lines starting with + were added, and unmarked lines are unchanged context shown to help locate the change. It's the same format produced by `diff -u` and used in patch files.
Does this compare word by word instead of line by line?: No — this tool diffs whole lines, which is the standard approach for comparing config files, logs and code. For a single sentence edited in place, a word-level diff would show less noise, but line diffs are far more common for real files.
Why do unchanged lines still appear in the output?: A few lines of surrounding context (3 by default) make it much easier to see where in the file a change happened, rather than showing added/removed lines with no anchor.