Diff & Compare Tools
Compare text, code, and data files. Find differences between versions with visual highlighting.
Finding the difference between two versions is the first step of most debugging sessions. These comparison tools handle text, JSON, XML, and images, including a three-way merge view for resolving conflicts.
5 tools availableA diff shows you two files; a comparison has to decide what equal means
Every comparison tool answers one question before it shows anything: equal under which rules? For plain text the answer is line-based and boring. For structured data it is a specification decision, and a comparison that ignores it reports differences nobody cares about - or misses ones that matter.
Context lines, and the exit code that trips up build scripts
The GNU diffutils manual describes what a hunk actually contains: "Notice that up to three lines that are not different are shown around each line that is different; they are the context lines." The unified format then "is a variation on the context format that is more compact because it omits redundant context lines" - which is why the same change can look different in two tools while being identical.
POSIX defines diff's exit status, and it is worth quoting in full: "0 No differences were found. 1 Differences were found and all differences were successfully output. >1 An error occurred." A script that treats any non-zero exit as a crash reports an ordinary difference as a broken tool, and a script that treats every non-zero exit as a difference never notices the real failure.
Structured formats define equality themselves
JSON Patch spells out what test means, and the rules differ by type: "strings: are considered equal if they contain the same number of Unicode characters and their code points are byte-by-byte equal", while "numbers: are considered equal if their values are numerically equal". The specification's own example then fails on purpose, because the document holds a number "whereas the value being tested for is a string". Ordering matters too: "the ordering of the serialization of object members is not significant", so a byte comparison is the wrong tool for JSON.
A patch's test operation is also a guard, because "the HTTP PATCH method is atomic, as per RFC 5789. Therefore, the following patch would result in no changes being made to the document at all (because the 'test' operation results in an error)". XML takes the other road: it canonicalises first, defining "a physical representation, the canonical form, of an XML document that accounts for the permissible changes", and notes that "if two documents have the same canonical form, then the two documents are logically equivalent".
| Comparison | What counts as equal | Detail that changes the verdict | Source |
|---|---|---|---|
| Text lines | the line sequence, with context shown around each change | exit 1 means differences were found; only >1 is an error | GNU diffutils; POSIX diff |
| JSON documents | type-specific equality - strings byte-by-byte, numbers by value | the string "10" and the number 10 are not equal; member order is irrelevant | RFC 6902, section 4.6 |
| XML documents | identical canonical form | namespace and attribute handling is normalised before comparison | W3C Canonical XML 1.1 |
| Images | whatever threshold you chose | no specification defines image equality - state the tolerance in the test | tool-defined |
Compare two revisions with Text Diff, ignore key order with JSON Diff, canonicalise before comparing with XML Diff, set an explicit tolerance with Image Diff, and resolve both sides of a conflict with 3-Way Merge.
Sources: GNU diffutils manual, context and unified formats; POSIX diff, exit status; RFC 6902, JSON Patch; W3C Canonical XML Version 1.1.