Text Diff
Line-by-line comparison using a Myers-style longest common subsequence.
Ignore case
Ignore whitespace
Original
Changed
+2
-1
2 unchanged
Only changes
11 the quick brown fox
2-jumps over
2+leaps over
33 the lazy dog
4+and naps
Compare two blocks of text line by line and see exactly what changed — for config files, API responses, translations or a paragraph someone edited without telling you.
Two files that look identical and behave differently usually differ in something invisible: a trailing space, a tab where the other has spaces, or CRLF line endings from Windows against LF from everywhere else. A visual comparison misses all three; a character-level diff does not.
This page compares line by line and then within each changed line, so a one-word edit in a long paragraph is shown as that word rather than as the whole line being replaced. Options to ignore case and whitespace are there for the case where the difference you are hunting is genuinely the content.
A diff is not a list of what changed; it is the shortest edit script that turns one text into the other, and those are not always the same thing. The usual algorithm searches for the longest common subsequence, so a block of lines moved from the top of a file to the bottom is reported as a deletion in one place and an insertion in another rather than as a move. Knowing this saves time when a reordered configuration file looks as though it has been rewritten from scratch: the content is intact, and what you are reading is the algorithm describing a move in the only vocabulary it has.
Some differences are invisible because the characters themselves are. A Hangul syllable can be stored as a single code point or as its component jamo — 한 is either U+D55C or the sequence U+1112 U+1161 U+11AB — and text that has passed through macOS can arrive decomposed while the same text from elsewhere is composed. Non-breaking spaces pasted from a web page, zero-width joiners left behind by an editor, and the two different apostrophe characters all produce the same effect: a line marked as changed where both versions look identical on screen. When that happens this is almost always the explanation, and it is the case a character-level comparison exists to catch.
The whitespace options are a judgement call rather than a convenience. Ignoring whitespace is right when comparing prose, or a source file that has simply been reformatted, and wrong for Python, YAML and Makefiles, where indentation and the tab character are part of the meaning — a diff that hides them hides the bug you are looking for. The same reasoning applies to a minified and a pretty-printed copy of the same JSON: formatting both sides the same way first turns a report that every line changed into a report of the one field that actually differs, which is the comparison you wanted in the first place.
This is a two-way comparison, which is worth distinguishing from the three-way diff a version control system performs during a merge. A two-way diff shows that two files differ; it cannot tell which side changed, because it has no record of what they both started from. That is precisely what a merge tool adds — the common ancestor — and why it can accept one side automatically where a two-way view can only report a difference. For reviewing an edit, comparing two exports, or checking a config against a known-good copy, two-way is the right shape and the ancestor would add nothing.
No. The comparison runs entirely in your browser.
Paste their contents into the two panes; comparison is on text, not files.
The comparison is line-based, which is the right granularity for code and config. For prose, break long paragraphs into shorter lines first.