Compare JSON by key, not by line

Because those tools are comparing the text, not the data. In JSON the sequence an object's members are written in carries no meaning, so {"a":1,"b":2} and {"b":2,"a":1} hold identical information — but as strings of characters they are plainly different, and a line-based comparison has no way to know the difference does not matter. Serialisers reorder constantly: Go's encoding/json sorts map keys alphabetically, Python's json.dumps preserves insertion order, JavaScript promotes every key that could pass for an array index ahead of the rest. This page pairs members by name from the start, so all of that disappears, and how many objects were reordered is reported as information rather than as a difference.

Switch array matching to “by identity key” and name the field that identifies an item. Position matching is the honest default because JSON arrays genuinely are ordered — [1,2] and [2,1] are different documents, and pretending otherwise would be wrong. But a list of orders keyed by id is a collection that happens to be stored in an array, and comparing it by position turns a re-sorted API response into a hundred false differences. With an identity key, an item that only moved is reported as moved, an item whose values changed is reported at its new position, and only genuinely new or missing items count as additions and removals.

Yes by default, and you can switch that off. Both literals are rewritten as an exact decimal string before they are compared — the exponent is applied by moving the decimal point, then trailing zeros are dropped — so 1, 1.0, 1e0 and 0.1e1 all collapse to the same form. The obvious alternative, comparing Number(a) === Number(b), would agree about those and then get the important case wrong: 9007199254740993 and 9007199254740992 are the same 64-bit float and different integers, and an order ID that differs in its last digit is exactly the difference you cannot afford to miss. Shifting the decimal point by hand keeps every digit.

Both occurrences survive the parse, the second one is what gets compared, and the path is listed as a warning. The standard only recommends unique names rather than requiring them and leaves the result undefined when a document ignores that advice, so the useful reading is whichever value your own code will end up with — and in practice every mainstream parser resolves a repeated name to the value written last. Comparing anything else would answer a question nobody asked. The warning earns its place because a repeat is invisible the moment a document has been through a parser, and it nearly always means the template or the merge step that produced the file is emitting a field twice.

No. Strings are compared by the characters they decode to, not by the escapes used to write them, so "caf\u00e9" and "café" are equal — as are "a\/b" and "a/b", since the forward-slash escape is optional in JSON. Serialisers differ here for no reason that concerns you: Python's json.dumps escapes non-ASCII by default, JavaScript's JSON.stringify does not, and PHP does unless you pass JSON_UNESCAPED_UNICODE. The count of strings that matched only after unescaping is shown in the status bar, because occasionally that is the thing you were looking for.

5 MB a side and 500 levels of nesting. A realistic 5.33 MB pair — 24,000 records, 456,001 nodes, 336,000 keys — parses in about a tenth of a second per document and compares in 137 ms when arrays are matched by position, or 180 ms by identity key. The deliberately awkward case, two 5.33 MB documents where every object has its keys in the opposite order, returns “structurally equal” in 143 ms and reports 24,000 reordered objects.

No. Both are parsed and compared by JavaScript inside this tab, so a database export or a customer payload can be checked here without any of it leaving the machine.