Tool
JSON Patch Validator
Check that an RFC 6902 patch is well-formed - and, more importantly, that it does what you expect when it meets a real document.
To validate a JSON Patch, check two things. First the structure: the patch is a JSON array, every operation has a valid op name and path, and the required members (value for add/replace/test, from for move/copy) are present. Then the behaviour: apply or verify the patch against a real document, because a well-formed patch can still fail on missing paths, out-of-range indexes and test mismatches.
Validate a patch right now
The Verify mode loads a source document, your patch and the expected result - and gives you a pass/fail verdict with the exact failing operation.
Open the validator with an exampleWhat makes a patch well-formed
RFC 6902 defines the shape of a patch document. A conforming patch passes all of these checks:
- The document is a JSON array of operation objects.
- Every operation has an
opmember naming one of the six operations:add,remove,replace,move,copy,test. - Every operation has a
pathmember holding a valid JSON Pointer. add,replaceandtestalso carry avalue;moveandcopycarry afrompointer.- Members the RFC does not define are ignored - they do not make a patch invalid, but they do nothing.
What well-formed does not guarantee
Structural validation is only half the story. A perfectly formed patch can still fail against a specific document: the path it removes may not exist, an array index may be out of range, or a test operation may find a different value than expected - including type mismatches like 1 vs "1". Those are runtime failures, not syntax errors, and the only way to catch them is to run the patch against the real document.
That is exactly what the Verify mode does: paste the source document, the patch and the result you expect, and it tells you whether the patch gets you there - and where it breaks if it does not. The JSON Patch errors guide explains every failure message you can hit.
An invalid patch, annotated
Three errors in four lines
[
{ "op": "update", "path": "/version", "value": 2 },
{ "op": "add", "path": "/tags/-" },
{ "op": "replace", "path": "/a/b/timeout", "value": 60 },
]The first operation uses update, which does not exist - the name is replace. The second is an add without a value. The third targets a key literally named a/b without escaping the slash - the path should be /a~1b/timeout. And the trailing comma after the last operation makes the whole document unparseable JSON.
Tested failure
Verified 19 September 2026 with fast-json-patch 3.1.1. Against { "version": 2 }, a first operation of { "op": "test", "path": "/version", "value": 1 } produced TEST_OPERATION_FAILED; the following replace operation was not evaluated.
The most common validation errors
Unknown operation name
Only six operation names exist: add, remove, replace, move, copy, test. "update", "delete" or "set" are not valid - use replace, remove and add.
Missing value on add, replace or test
add, replace and test all require a value member. remove needs none, and move and copy need from instead.
Unescaped JSON Pointer paths
Inside a path, ~ and / must be escaped as ~0 and ~1. A key literally named "a/b" is addressed as /a~1b.
Patch wrapped in an object
A patch document is a JSON array of operations, starting with [. Wrapping it in an object like { "patch": [...] } makes it invalid.
Trailing commas or comments
A patch is plain JSON. Trailing commas, // comments and single quotes are all syntax errors.
Frequently asked questions
Does a valid patch always apply cleanly?
No. Validity is about the patch document itself. Applying also depends on the target document: every remove, replace and test path must exist, and array indexes must be in range. Verify against the real document to be sure.
Do I have to include test operations?
They are optional, but they are the only way to make a patch fail safely when the document has drifted. For anything that writes to shared or production data, guard the assumptions with test first.
Can I validate a patch without applying it?
Structurally, yes - the checks above are enough. But the only way to know a patch produces the document you want is to run it. Verify mode does that in your browser without sending anything to a server.