Detecting Changed Values in JSON

A changed value (or modification) occurs when the same key exists in both JSON documents but holds a different value. This is the most common type of diff operation and covers changes to strings, numbers, booleans, nulls, and even structural replacements.

How value change detection works:

The algorithm walks both documents simultaneously. When a key exists in both, the values are compared:

• Primitives (strings, numbers, booleans, null) are compared with strict equality. If they differ, a "replace" or "change" operation is recorded showing both the old and new values.
• Objects are compared recursively, descending into nested structures.
• Arrays require special handling (see the array-differences example).

// Before
{
  "version": "1.2.0",
  "maxRetries": 3,
  "debug": false,
  "endpoint": "https://api.example.com/v1"
}

// After
{
  "version": "1.3.0",
  "maxRetries": 5,
  "debug": true,
  "endpoint": "https://api.example.com/v2"
}

This diff reports four value changes. The algorithm preserves both the old and new values, making it easy to review exactly what shifted.

RFC 6902 representation:

JSON Patch uses "op": "replace" for value changes, including the target "path" and the new "value". The old value is not included in the patch (it is assumed you are applying the patch to the known original).

Types of value changes:

1. Same-type changes: "1.2.0" -> "1.3.0" (string to string). These are the most common and easiest to review.
2. Cross-type changes: false -> "no" (boolean to string). These are often bugs or intentional schema migrations.
3. Structural changes: "Portland" -> { "city": "Portland", "state": "OR" } (scalar to object). These are significant refactors.

Best practices for reviewing value diffs:

• Sort changes by path depth to see top-level changes first.
• Filter by type (e.g., show only numeric changes) when reviewing large diffs.
• Pay special attention to cross-type changes, as they may indicate unintended data corruption.