Paste two pieces of text or code and instantly see what was added, removed and changed, line by line — right in your browser.
🔒 The comparison runs entirely on your device — your text is never uploaded.
Spot exactly which lines changed between two versions of a file or snippet.
Compare drafts of an article, contract or email to see every revision.
Catch small differences between two lists, configs or logs in seconds.
There is no single correct diff between two texts, only ones that are cheaper or more readable. The problem is formally the longest common subsequence: find the largest set of lines appearing in both documents in the same order, and everything outside it is an insertion or a deletion. The classic solution is Eugene Myers' 1986 algorithm, which is what most tools including Git use by default, and it runs in time proportional to the product of the document length and the number of differences.
That "number of differences" term is why diffing two similar files is fast and diffing two unrelated ones is slow. It is also why a file where every line changed — a re-indentation, or a line-ending conversion — takes far longer and produces a useless result.
Myers finds a minimal diff, but minimal is not always readable. When a block is inserted next to similar text, it will happily align the closing brace of the new block with the closing brace of the old one, producing hunks that start and end in visually strange places. Git ships alternative heuristics — patience and histogram — that prefer to anchor on lines that appear exactly once in both files, which usually yields hunks that match how a human would describe the change.
Comparing by line is the right default for code, because a line is a meaningful unit and the output maps onto how you edit. Its weakness is that changing one character marks the whole line as replaced, which is noisy for prose where a paragraph may be a single long line.
Word-level comparison suits prose and produces the inline highlighting you want when reviewing edited text. Character-level is finer still and is useful for short strings — a changed identifier, a modified URL — but on longer documents it degenerates into confetti, matching stray letters across unrelated words because they technically form a common subsequence.
A practical approach is to diff by line first to locate the changed region, then look at the word-level detail within it. That is exactly the hierarchy code review tools present.
The most frustrating diff is one showing every line as changed when the text looks the same. Almost always the cause is line endings: Windows uses CRLF, Unix and macOS use LF, and the carriage return is invisible in most editors. A file that has been through a Windows editor once will differ from its original on every single line.
Trailing whitespace is the next candidate — spaces at the end of a line that no editor renders — followed by tabs versus spaces, which look identical at the same visual width. Then there are characters that are genuinely invisible: a UTF-8 byte-order mark at the start of a file, non-breaking spaces pasted in from a word processor or a web page, and smart quotes substituted for straight ones by autocorrect.
If two files should be identical and are not, comparing their byte lengths is the fastest first check, and normalising line endings before diffing usually resolves it.
Paste the original on the left and the changed text on the right. It compares line by line — added lines are green, removed lines are red, unchanged lines are dimmed.
Yes — toggle "Ignore case" and "Ignore whitespace" so trivial differences don't count.
Completely — the comparison happens in your browser and nothing is uploaded.
Yes, completely free with no sign-up.
Almost certainly line endings — one file uses Windows CRLF and the other Unix LF, and the carriage return is invisible. Trailing whitespace and tab-versus-space differences produce the same effect.
Line for code, since a line is the unit you edit and review. Word for prose, where a paragraph is often one long line and line comparison would mark the whole thing as replaced.