How to compare two JSON documents

Paste the original document on the left and the edited one on the right, press Compare, and the page reports every added, removed and changed value by path — 7,143 changes for two 50,000-key objects, listed in the order the walk finds them.

The output is a JSON Patch (RFC 6902) that turns the first document into the second: an array of add, remove and replace operations carrying JSON Pointer paths. Both panes are parsed and compared inside the page, so nothing is uploaded and the comparison keeps working once the network drops.

Paste the before document into the left pane and the after document into the right one. Load example fills both with a small pair if you want to see the shape of the output first.
Press Compare. The counters appear above the list — added, removed, changed — and each row carries the pointer to the value plus a preview of it capped at 120 characters.
Read the patch underneath: the complete RFC 6902 document, indented, ready to paste into a test suite, a migration script or an HTTP PATCH request.
Copy patch puts it on the clipboard and Clear empties both panes. When a pane fails to parse, the status line names which document is at fault — Before JSON or After JSON — together with the error position, and the previous result is discarded.

What the patch says, and what it leaves out

What counts as a difference

Object key order is not a difference: {"a":1,"b":2} against {"b":2,"a":1} reports 0 changes. Numbers are compared as JavaScript doubles, so 1 and 1.0 are the same value, while 1e2 arrives as 100 and shows up as one change.

Types are never coerced: 1 against "1" is a change and true against 1 is a change, and a key holding null is not the same as a missing key — null in the first document and absent from the second gives remove /a rather than a match. Duplicate keys keep the last value, because the pane is read with JSON.parse, so {"a":1,"a":2} against {"a":2} reports 0 changes.

Arrays are compared by index

There is no move operation in the output. An array is walked position by position, so a reorder surfaces as a run of replace operations: [1,2] against [2,1] gives replace /0 with 2 and replace /1 with 1.

Length changes are emitted from the tail: [1,2,3,4] against [1,2] removes /3 first and then /2, and [1,2] against [1,2,3,4] adds /2 and /3. That order keeps every operation valid when the patch is applied top to bottom.

Pointers, escaping and empty keys

Each path is a JSON Pointer as defined by RFC 6901. A key containing a slash or a tilde is escaped: a/b appears as /a~1b and c~d as /c~0d.

An empty key still gets a pointer — the path reads / — and the document root has the empty path, so replacing the whole document is a single operation with path "".

Where the comparison runs

Parsing and comparing happen in the page. Loading the tool and comparing two 50,000-key objects sent no request beyond the page assets, so the documents stay in the browser; once loaded, the tool also works with the network off.

The limits of the JSON parser carry over: integers above 2^53 lose precision, so 9007199254740993 and 9007199254740992 are reported as identical, and a document nested 20,000 levels deep was compared and patched without error. Cost tracks the number of changes — 50,000 keys took about half a second and produced a 511 KB patch, 500,000 keys about five seconds and 5.25 MB. Read the patch before applying it to production data.