Why one array insertion can produce three changes

You add one item to the beginning of an array. The comparison reports three changed paths. This can be correct: a comparison by position answers a different question from a comparison by record identity.

Run the insertion example

Open JSON Compare and choose Array shift, or paste the following documents into the Before and After editors.

Before:
{"items":["alpha","beta"]}

After:
{"items":["new","alpha","beta"]}

The expected report contains exactly these three entries:

changed  /items/0  "alpha" → "new"
changed  /items/1  "beta"  → "alpha"
added    /items/2           "beta"

Diggwigs compares array indexes. It does not try to infer a stable ID or detect a move. This rule is predictable for primitive lists, nested arrays, and objects alike.

Object key order is different

For an object, the keys identify members. Reordering the keys does not change the values. Paste this pair to verify that formatting and insertion order do not create differences.

Before: {"count":1,"ready":true}
After:  {"ready":true,"count":1.0}

Expected report: []
Expected status: No differences

JSON numbers compare by exact mathematical value, so 1 and 1.0 are equal. Large integers are never routed through a floating-point number for comparison. Duplicate keys are rejected because they make object membership ambiguous.

Read the path literally

Reports use JSON Pointer paths. The empty path means the root value. A slash inside a key is escaped as ~1, and a tilde as ~0. For example, the key a/b has the path /a~1b.

If your product needs identity-based list comparison, define the identity field and the behavior for duplicates and missing IDs before comparing. For this workspace, the explicit rule remains position by position.

A difference is an answer to a comparison rule. Read the rule before interpreting the count.