JSON Patch (RFC 6902) Evaluator｜Apply the 6 Ops and See the Result

Run a JSON Patch against a document right in the browser, no server needed. The six standard operations — add, remove, replace, move, copy, and test — are applied in order, and you get the patched JSON plus a human-readable trace of what each op did. If any single op fails, the whole patch fails and the original document comes back, exactly as RFC 6902 requires.

💡 About this tool

When you're building or reviewing a PATCH endpoint, you constantly need to answer one question: "If I send this operations array, what does the document look like afterward?" Spinning up the real API, crafting the request, and reading the response is a slow loop — especially when you're unsure how move and copy differ, whether a test op will pass, or how the array-append - token behaves.

This evaluator collapses that loop into two text boxes. Paste a target document and an operations array, and it resolves every path with RFC 6901 JSON Pointer syntax and applies the ops the way the spec says. When something breaks, it tells you which op failed (like op[2]) and why — path not found, array index out of range, test value mismatch, or an unknown op. It's aimed at backend developers, OpenAPI reviewers, and anyone wiring up kubectl patch --type=json who wants to reproduce the spec's behavior without hitting a live server.

🧐 Frequently Asked Questions

Q. What's the difference between JSON Patch (RFC 6902) and JSON Merge Patch (RFC 7396)? A. JSON Patch is an array of explicit operations (add, remove, replace, move, copy, test) applied in order. Merge Patch sends a partial document representing the desired end state, using null to delete keys, and has no move, copy, or test. Reach for JSON Patch when you need precise array manipulation or a precondition check.

Q. What is the test op actually for? A. It's a guard that verifies a value at a path equals what you expect before any mutation runs. Putting test /version == 15 first lets the rest of the patch apply only if the document is still in the state you assumed — a clean way to do optimistic concurrency and avoid clobbering someone else's edit.

Q. What happens if one operation fails? A. RFC 6902 treats a patch atomically. The moment an op fails, the entire patch is considered failed, and this tool returns the original target document untouched. There's no partial apply.

Q. What does the - in /user/tags/- mean? A. It's the special JSON Pointer token for "the end of the array." Using - with add appends to that array; a numeric index inserts at that position instead.

Q. How do I reference a key that contains a slash or tilde? A. Use RFC 6901 escaping: write / inside a key as ~1 and ~ as ~0. So a key literally named a/b is addressed as /a~1b.

📚 Why JSON Patch fits REST PATCH so well

REST's PATCH verb means "partial update," but HTTP itself never defines the body format. Carrying a JSON Patch in that body lets you describe a change as a sequence of operations rather than a whole replacement document. Compared with PUT, the payload is small, and pairing mutations with a test op prevents you from silently overwriting a field someone changed since you read it. The operations array also doubles as a readable audit trail — you can see exactly who changed which path and how. Tools like kubectl patch --type=json accept this same RFC 6902 format. In practice, the fastest way to internalize the difference between move and copy, or to feel how test aborts a patch, is to line up a few ops and watch the result rather than re-reading the RFC.