JSON Patch Applier

What is JSON Patch (RFC 6902)?

JSON Patch is a standard format for describing changes to a JSON document as an ordered list of operations. Instead of sending a whole updated document, an API client can send a small array like [{"op": "replace", "path": "/status", "value": "active"}] and the server applies it atomically. It is the format behind HTTP PATCH with the application/json-patch+json media type, and it is used by Kubernetes (kubectl patch --type=json), Azure and Google Cloud APIs, and many REST backends.

Each operation targets a location with a JSON Pointer (RFC 6901) path such as /users/0/email. Operations are applied in order, and if any operation fails — for example a test that doesn't match, or a remove on a missing key — the whole patch is rejected. This applier reports exactly which operation failed and why.

JSON Patch vs JSON Merge Patch (RFC 7396)

JSON Merge Patch is the simpler sibling: the patch is itself a JSON document that mirrors the target's shape. Keys you include are updated, keys set to null are deleted, and everything else is left alone. It is ideal for partial updates of flat-ish objects, but it cannot express array element edits, moves, or conditional tests.

Use RFC 6902 JSON Patch when you need precise, ordered operations — especially inside arrays — or want test operations for optimistic concurrency. Use RFC 7396 Merge Patch when you just want to overlay a partial object. JsonDrift supports both modes with a single toggle, so you can experiment with the same document and see how the semantics differ.

Supported operations

• add — insert a value at a path, including array positions and the '-' end-of-array pointer
• remove — delete the value at a path
• replace — swap the value at an existing path
• move — remove from one path and add at another
• copy — duplicate a value from one path to another
• test — assert a path equals a value; the patch fails if it doesn't
• Merge Patch mode — apply an RFC 7396 partial document with null-deletes

Common workflows

Debugging PATCH requests: paste the resource from your API and the patch body from your client to verify the result the server should produce, before you blame the backend.

Kubernetes and infrastructure: preview what a kubectl patch operation will do to a manifest without touching the cluster.

Round-tripping with the patch generator: create a patch from two versions using the JSON Patch Generator, then apply it here to confirm it reproduces the target document exactly.

Config migrations: keep a patch file as a reviewable, minimal description of a config change, and apply it to each environment's JSON.

Privacy: patches applied locally

Both the document and the patch are processed entirely in your browser. Nothing is uploaded, logged, or stored on a server, which makes this safe for production configuration, customer records, and internal API payloads.