Skip to content

Compare two texts

Paste both versions and see exactly what changed, side by side, down to the individual words. The same algorithm git uses — not a line-by-line guess that falls apart when you add a line.

  • Never stored
  • No queue, no waiting
  • No signup, no watermark
View

How it works

1

Paste both versions

Original on the left, new on the right. Or drop two files in.

2

Read the differences

Added, removed and changed lines are marked, and within a changed line the exact words are highlighted.

3

Ignore what does not matter

Capitalisation, spacing and blank lines can each be ignored — and the page tells you when that is the only reason two texts match.

What counts as the same line

Comparison happens on a key rather than on the line itself. Each line is reduced to a key according to whichever ignore options are switched on, the diff runs over the keys, and what you are shown is always your original text — so turning on "ignore capitalisation" changes which lines match without altering a character of what is displayed. There are two separate whitespace options and they differ more than their labels suggest: one trims the ends of a line, the other first collapses runs of spaces and tabs down to a single space and then trims. Neither removes whitespace altogether, and the collapsing looks for literal spaces and tabs only, so an ideographic space or a non-breaking space in the middle of a line is left alone and still registers as a difference.

Ignoring blank lines is the option with a consequence nobody mentions: the blank lines are removed before the comparison runs, so the line numbers beside the result count only the lines that survived, and stop matching the line numbers in your file. With the option off, they match exactly. The word-level highlighting inside a changed line follows the ignore-capitalisation setting and nothing else — the whitespace options do not reach it, so spacing differences inside a line that was changed for some other reason are still painted as changes.

The copyable result is a unified diff in every way that matters for reading it — the two file headers, minus lines, plus lines, three lines of context around each change — with one exception worth knowing before you rely on it. Its hunk markers carry no line ranges, so it is made for a bug report, a code review comment or an email, and the patch and git apply commands will refuse it. If what you need is something to apply rather than something to read, produce it with git.

When you want something else

Structured formats compare badly as lines, and the failure is loud rather than subtle: two JSON documents differing only in the order of their keys, or two CSVs with one column moved, come back as a wall of changes that tells you nothing. Diff them with something that understands the shape instead — sort the keys of both JSON files first and compare the results, or use daff, which diffs CSV as rows and columns and will tell you a column moved rather than that every line changed.

Two directories, or two points in a repository's history, are git's question rather than this page's. And for prose where the paragraphs have been rewrapped, a line-based view is the wrong granularity entirely — git diff --word-diff ignores where the line breaks fell and shows you only the words that moved, which is the comparison you actually wanted when a document has been reflowed.

Frequently asked questions

Are my documents stored anywhere?

No. Nothing is stored and no request is made, and it keeps working with the network disconnected. That matters more than it looks for text: what people paste into an online tool is unpublished writing, legal drafts, student work and internal documents. For comparing two versions of a contract or a draft, that is the whole point.

Why is this better than comparing line by line?

Because a line-by-line walk breaks the moment anything moves. Add one line to the top of a file and every line below it is now on a different row, so a naive comparison reports the entire document as changed — which is useless. This uses Myers' algorithm, the one behind git diff and diff(1), which finds the smallest set of insertions and deletions that turns one text into the other. Add a line at the top, and it reports one added line.

Can it show which words changed, not just which lines?

Yes. When a line has been edited rather than added or removed, it is compared again word by word and only the words that actually changed are highlighted. On a long paragraph where someone changed three words, you see three words, not a wall of colour.

What do the "ignore" options do?

They change what counts as the same line. Ignoring capitalisation, or spacing, or blank lines is useful when comparing reformatted code or re-pasted text. One important detail: if two texts match ONLY because something is being ignored, the page says so explicitly rather than reporting them as identical — "identical" and "identical if you ignore case" are different facts, and confusing them is how someone ships a file they believed was unchanged.

Can I get the result as a patch?

Yes — the comparison can be copied as a unified diff, the same format git and email patches use, with a few lines of context around each change. That is the format to paste into a bug report.

Is there a size limit?

Available memory, rather than a fixed size cap. Comparing two long documents is fast because the identical beginning and end are matched and skipped before the real work starts. Two texts that differ in thousands of separate places will be refused with an explanation rather than freezing the tab — a diff that large is not readable anyway.

Can it compare Word or PDF files?

Not directly. Convert them to text first — our [PDF to Text](pdf-to-text) and [DOCX to TXT](docx-to-txt) tools do exactly that — and paste the results here.

Good to know: The comparison is capped at 8,000 differences. Past that the algorithm's cost grows fast enough to freeze the tab, so the page stops and says so rather than hanging — two genuinely unrelated documents hit this quickly. Comparing two versions of the same file almost never does.

Put this tool on your website

Free for any blog, class page or help article. Paste one snippet and your visitors can use it right on your page.