JSON Patch Generator

Compare two JSON documents and generate RFC 6902 JSON Patch operation sets.

Preset Sample Payloads

Original JSON (A)Valid JSON

Modified JSON (B)Valid JSON

Operations5 ops

By operation2 add • 3 replace • 0 remove

Size A / Size B159 B / 216 B

Patch size389 B

JSON Patch (RFC 6902)

Add test operations, so each value is checked before it is replaced or removed

[
  {
    "op": "replace",
    "path": "/name",
    "value": "Alice Smith"
  },
  {
    "op": "replace",
    "path": "/roles/1",
    "value": "moderator"
  },
  {
    "op": "replace",
    "path": "/address/zip",
    "value": "10002"
  },
  {
    "op": "add",
    "path": "/address/country",
    "value": "US"
  },
  {
    "op": "add",
    "path": "/phone",
    "value": "+1-555-0100"
  }
]

JSON Patch Generator — create RFC 6902 patch documents from JSON diffs

RFC 6902 JSON Patch is a standard format for expressing a sequence of operations to apply to a JSON document. Each operation is an object with an op field (add, remove, replace, move, copy, or test), a path using JSON Pointer notation, and optionally a value. JSON Patch is used in REST APIs (PATCH requests), version control systems for JSON data, and anywhere a change is sent rather than the whole document. This tool compares objects member by member and arrays by edit distance, so an element inserted into an array is one add, not a change to every element after it. A change to the whole document has the path "", since / names the member whose key is empty. Any key is read as a key, __proto__ and constructor included, and each number keeps its digits, so a 20-digit ID is not rounded. With test operations on, each replace and remove first checks the value it changes, so the patch fails on a document that has changed since.

Built and maintained by Meet Shah · Last updated 9 October 2026

What this tool is used for

Producing an RFC 6902 patch between two documents.
Generating a PATCH body for an API that accepts JSON Patch.
Understanding how a change is expressed as operations.
Checking a patch before sending it to a live endpoint.
Comparing JSON Patch against Merge Patch for one change.

Frequently Asked Questions

What standard does the output follow?: RFC 6902 JSON Patch: an array of operations, each with an op and a JSON Pointer path. The generator writes add, remove and replace, and with test operations on, a test before each replace and remove. Applied in order to A, the patch gives B.
How are the paths written?: As JSON Pointers (RFC 6901). Each key or index follows a /, so a / inside a key is written ~1 and a ~ is written ~0, and a/b is not read as two levels. The whole document is the empty path "": a path of / names the member whose key is the empty string.
How are array changes handled?: By edit distance. The elements both arrays keep are left alone, and the fewest additions, removals and replacements turn the rest of A into B, so an element inserted at the front is one add, not a change to every later index. An array too long to search is compared by position, and a note says so.
Does it emit move or copy operations?: No. Both are in the specification, but detecting them requires matching relocated values across the document, and a patch built only from add, remove and replace applies to the same result.
Where is JSON Patch actually used?: HTTP PATCH bodies with application/json-patch+json, Kubernetes resource updates, and change feeds where sending the delta beats sending the document. The byte comparison shown tells you whether the patch is genuinely smaller.
How does it differ from JSON Merge Patch?: A merge patch (RFC 7396) is a partial copy of the document in which null means remove the key. That is simpler, but a merge patch cannot set a value to null, and it can only replace an array whole. JSON Patch names each change, so it can do both.
What do test operations add?: A test checks that the document holds a value before the next operation changes it. With them on, each replace and remove comes after a test of the value A holds there, so on a document that has changed since, the patch fails rather than overwriting the newer edit. Numbers are compared by value, so 1.0 equals 1.
Are numbers and keys kept exactly?: Yes. The documents are read as written, not through JavaScript objects, so a 20-digit ID is not rounded, 59.90 stays 59.90, keys keep their order, and __proto__, constructor and toString are ordinary keys. Key order and how a number is written are not data, so they are never changes.

Common errors and gotchas

Confusing JSON Patch with JSON Merge Patch, which are different specifications and media types.
Writing / as the path of the whole document: it names the member whose key is the empty string, and the whole document's path is "".
Omitting a test operation where the patch depends on a precondition.
Escaping a path segment incorrectly, where / and ~ need encoding in a pointer.
Assuming the server applies operations atomically, which the specification requires but not every server honours.