JSON Patch Generator
Diff two JSON documents into an RFC 6902 JSON Patch, or apply an existing patch to a target document.
Stop hand-writing PATCH bodies or diffing JSON documents by eye. Paste an original and an updated document to get a standards-compliant RFC 6902 patch back, or paste a target document and a patch to see exactly what applying it produces — both directions run entirely in your browser.
- ✓Generates add, remove and replace operations from a real diff
- ✓Applies all six RFC 6902 operations, including move, copy and test
- ✓Correct JSON Pointer escaping for ~ and / in key names
- ✓Catches a failed test assertion instead of silently applying a stale patch
- ✓No account, no upload — everything runs client-side
What is a JSON Patch?
A JSON Patch (RFC 6902) is a JSON document describing a sequence of operations to apply to another JSON document — instead of sending a whole updated document over the wire, you send just the changes. It's the format behind PATCH requests in many REST APIs, Kubernetes' strategic merge patches, and config-management diffing tools.
Each operation is one of six kinds — add, remove, replace, move, copy, test — targeting a location with a JSON Pointer path like /user/tags/0.
JSON Patch vs. JSON Merge Patch vs. a Diff View
| JSON Patch (RFC 6902) | JSON Merge Patch (RFC 7396) | JSONKit's JSON Diff | |
|---|---|---|---|
| Format | Array of operations | A partial document to merge | A visual, human-readable comparison |
| Can remove a key | Yes — explicit remove op | Yes — set value to null | N/A (view only) |
| Can reorder / move values | Yes — move op | No | N/A |
| Machine-applicable | Yes — apply directly | Yes — shallow merge | No — for reading, not applying |
| Best for | Precise API PATCH bodies | Simple partial updates | Reviewing what changed |
Example
Given this change:
// Original
{ "name": "Ravi", "role": "editor", "tags": ["beta"] }
// Updated
{ "name": "Ravi Kumar", "role": "admin", "tags": ["beta", "verified"] }The generated patch:
[
{ "op": "replace", "path": "/name", "value": "Ravi Kumar" },
{ "op": "replace", "path": "/role", "value": "admin" },
{ "op": "add", "path": "/tags/1", "value": "verified" }
]Applying a Patch in Your Backend
// npm install fast-json-patch
import { applyPatch } from "fast-json-patch";
const target = { name: "Ravi", role: "editor", tags: ["beta"] };
const patch = [
{ op: "replace", path: "/name", value: "Ravi Kumar" },
{ op: "replace", path: "/role", value: "admin" },
{ op: "add", path: "/tags/1", value: "verified" },
];
const result = applyPatch(target, patch).newDocument;
console.log(result);
// { name: "Ravi Kumar", role: "admin", tags: ["beta", "verified"] }# pip install jsonpatch
import jsonpatch
target = {"name": "Ravi", "role": "editor", "tags": ["beta"]}
patch = jsonpatch.JsonPatch([
{"op": "replace", "path": "/name", "value": "Ravi Kumar"},
{"op": "replace", "path": "/role", "value": "admin"},
{"op": "add", "path": "/tags/1", "value": "verified"},
])
result = patch.apply(target)
print(result)Move, Copy and Test — the Other Three Operations
The generator only ever emits add, remove and replace — enough to describe any change unambiguously. But a hand-written or third-party patch can use all six operations, and the Apply Patch mode above supports every one of them:
[
{ "op": "test", "path": "/version", "value": 3 },
{ "op": "move", "from": "/draftTitle", "path": "/title" },
{ "op": "copy", "from": "/author", "path": "/lastEditedBy" }
]move relocates a value from one path to another in a single atomic step (equivalent to a remove then an add, but expressed as one intent). copy duplicates a value to a new path without removing the original. test doesn't modify anything — it asserts that the value at a path equals a given value, and aborts the entire patch if it doesn't match, which is the standard way to express optimistic concurrency control ("only apply this if nothing else changed /versionsince I read it") directly inside the patch document itself, with no separate ETag or version-check request needed.
Where JSON Patch Shows Up in Practice
- ▸REST API PATCH endpoints — Send only the fields that changed, with Content-Type: application/json-patch+json, instead of a full PUT replacement
- ▸Kubernetes strategic merge and JSON patches — kubectl patch and the Kubernetes API both accept RFC 6902-style patches for precise, partial resource updates
- ▸Optimistic concurrency control — A leading test operation aborts the whole patch if the resource changed since you last read it, avoiding a lost-update race
- ▸Config drift and change auditing — Store a patch alongside a change request as a precise, reviewable record of exactly what changed and where