To compare two JSON documents, parse both, decide whether object key order is noise, then compare the values. A line-by-line pretty-print diff will flag reordered keys as changes even when the objects are equal. A structural compare treats objects as maps and arrays as index lists.
Validate or format each side if you cannot tell whether the text is JSON. Then use the JSON Sorter when key order is the only git noise. Then use the JSON Diff to list added, removed, and changed paths. The JSON Formatter is for reading one side, not for declaring two sides equal.
If either box is illegal JSON, you do not have two documents yet. Trailing commas, comments, and single quotes fail parse. Fix the first token on that side. The procedure in how to format, validate and minify JSON applies independently to A and to B.
Whitespace and key order in the source text never reach a structural compare. They are gone after JSON.parse. Duplicate keys in the source text are also gone. You cannot recover a lost duplicate with a diff.
JSON object member order is not semantically significant. If your only difference is that one pretty-printer emitted name before id, sort both objects A→Z (or both Z→A) at every nesting level, then compare. Array item order is not noise. Do not sort arrays unless your API treats them as sets, and this site’s sorter does not reorder array items.
Sorting is a presentation step for humans and for git. It is not required when you already trust a structural diff that ignores object key order.
The diff lists paths such as user.email, tags[1], or (root). Added and removed keys are named. Changed values show both sides. The number 1 is not the string "1". An object versus an array at the same path is a type change.
Arrays are compared by index. If you insert at index 0, later indexes look changed. There is no move detection and no longest-common-subsequence. That is honest: the tool does not invent that item 2 “moved” to item 0.
Document A:
{"name":"Ada","age":30,"tags":["a","b"]}Document B, keys in another order:
{"tags":["a","c"],"name":"Ada","age":31,"email":"ada@example.com"}A text diff of pretty-printed files is noisy. A structural compare should report a changed age, a changed tags[1], and an added email. name stays equal. If you only sorted B and left the values the same as A, the diff should report no differences even though the source text still looks different.
It will not merge the two documents. It will not emit a JSON Patch. It will not decide that two array items are “the same user” because they share an id. If you need identity matching, you are writing application logic, not running this procedure.
If either document is larger than the traversal limit, the output is cleared. There is no half-diff to trust. Compare smaller fixtures, or compare the subtree you care about.
When you file a ticket, paste the path list, not a screenshot of two formatted blobs. “tags[1] changed, email added” is a fact someone can act on. “The JSON looks different” is not. This guide exists so a team can compare two JSON documents the same way twice.
Staging versus production fixtures are the usual pair. If staging sorted keys and production did not, a text diff of formatted files is a waste of the review. Parse both. If values match, stop. If updated_at is the only changed path and you expected that, exclude it by comparing a copy with that key removed. The diff tool will not ignore keys for you.
Type changes are easy to miss in a pretty-print. "1" and 1 look related in a spreadsheet and are different JSON values. A structural compare reports that path as changed. Believe the type, then decide whether the producer should emit a number.
If you need to show a human the two documents, format each side after you have the path list. Formatting first and then arguing about line wraps is the long way to the same ticket. Compare two JSON documents means parse, optionally sort object keys, then list value paths.
That was a text compare. Object key order is not JSON data. Sort both sides or use a structural compare that treats objects as maps.
This procedure does not detect moves. An insert at the start makes later indexes look changed. That is the comparison, not a bug in the listing.
Format if you need to read one side. Formatting is not the comparison. Parse errors still have to be fixed first.
Not with this procedure. The list is a report. A merge or patch is a different job.
