When is JSON Diff useful?
A JSON diff answers the question a text diff answers badly: what actually changed between two versions of a structured document. A text diff on JSON is noisy, because reordering keys, re-indenting a block, or minifying a file rewrites lines that carry no change in meaning. This page parses both documents first and then walks them together, so only a real difference appears: a path that exists on one side only, or a value that differs. Whitespace, indentation, and key order are ignored because they are already gone by the time the comparison starts.
Every line of the report is one path. A plus sign marks a path that exists only in the second document, a minus sign marks a path that exists only in the first, and a tilde marks a path whose value changed, with the old value and the new value on the same line. A path is written with slashes, so a city inside a customer object is reported as /customer/city and the second item of a list is /items/1, and a key that itself contains a slash is escaped so the path stays unambiguous. A change of type is called out as well, because a number that became a string breaks a comparison downstream even when the two look alike on screen.
This is also a JSON compare tool: it compares parsed values rather than raw line order. Two behaviours are worth knowing before reading a report. Arrays are compared by index, which is the honest way to compare a list without guessing intent: an item inserted at the front of a ten-item list shifts every later index and is reported as ten changes rather than one insertion. Numbers are compared as numbers, so 1 and 1.0 are equal, while the string 1 against the number 1 is a type change. The summary line counts added, removed, and changed paths, so the size of a change is visible before reading it. Both documents are parsed in the tab and neither is uploaded; when one of them fails to parse, the message names which side and at what line and column.