RFC 6902: Why the remove target location must exist

If applying a JSON Patch fails with a message like “remove operation target location must exist”, the path in your patch points at a field that is not in the document. RFC 6902 is strict: remove cannot silently skip a missing path.

Open this example in JSON Patch & Pointer

Open the tool, then paste the sample input below. Everything runs locally in your browser.

Open this example in JSON Patch & Pointer →

The problem

In RFC 6902 JSON Patch, a remove operation fails when its path does not resolve to an existing member or array element in the target document. Unlike a merge-style update, it will not no-op on a missing field — the whole patch is rejected.

The fix is to point remove at a path that exists, correct the JSON Pointer, or guard the operation with a test first.

Sample input

Original JSON
{
  "user": {
    "id": 101,
    "name": "Asha",
    "email": "asha@example.com"
  }
}
Patch (fails — /user/phone does not exist)
[
  { "op": "remove", "path": "/user/phone" }
]

Expected output

Fixed patch (remove an existing path)
[
  { "op": "remove", "path": "/user/email" }
]
Resulting JSON
{
  "user": {
    "id": 101,
    "name": "Asha"
  }
}

The first patch is rejected because /user/phone is not present. The corrected patch removes /user/email, which exists, and succeeds.

How to do it

  1. Paste the original JSON document into JSON Patch & Pointer.
  2. Paste the patch array and apply it.
  3. If it fails, read which operation index and path were rejected.
  4. Confirm the path actually exists in the document (watch nested keys and array indexes).
  5. Either fix the path, or prepend a test operation so a missing target fails loudly and predictably.

Common mistakes

  • Removing a field that is not present in the document.
  • Mistyping a nested path, e.g. /user/emai instead of /user/email.
  • Targeting an array index that is out of range.
  • Writing JSONPath ($.user.email) instead of a JSON Pointer (/user/email).
  • Expecting remove to be ignored when the target is missing — it is not.

Related tools

Related guides

FAQ

Why does JSON Patch remove fail when the path is missing?

RFC 6902 requires the target location of a remove operation to exist. If it does not, the operation — and the whole patch — is rejected rather than skipped.

Can JSON Patch ignore missing paths?

No. Standard RFC 6902 has no “ignore if missing” flag. If you want optional removal, check the path first or guard it with a test operation and handle the failure yourself.

Should I use test before remove?

Often, yes. A test operation before remove asserts the current value and makes a stale or wrong patch fail clearly instead of corrupting the document.

Is /user.email a valid JSON Pointer path?

No. JSON Pointer uses slash-separated segments, so the correct path is /user/email. Dotted paths are JSONPath-style and will not resolve.

How do I remove an array item with JSON Patch?

Use the element index, e.g. { "op": "remove", "path": "/items/2" }. The index must point at an existing element; removing index 2 of a two-element array fails.

Test JSON Patch operations locally in your browser before sending a PATCH request. Nothing you paste is uploaded to a server.

Explore more JSON and API contract tools

Schema validation, JSON Patch, JSON diff and JSONPath testing — grouped in one place.

View the JSON & API contract toolkit →

Practical example and expected result

If applying a JSON Patch fails with a message like “remove operation target location must exist”, the path in your patch points at a field that is not in the document. RFC 6902 is strict: remove cannot silently skip a missing path. In practice, this is most useful when you need a quick, repeatable check on a developer artifact before adding it to a ticket, pull request, test fixture, or support note.

A realistic input for this workflow is { "user": { "id": 101, "name": "Asha", "email": "asha@example.com" } }. The expected result should resemble [ { "op": "remove", "path": "/user/phone" } ], with the same important values preserved.

Troubleshooting checklist

  • Confirm you copied the complete developer artifact and not only a partial line or truncated preview.
  • Run the local tool once with a safe sample, then repeat with the real data only if your team policy allows it.
  • Check quoting, escaping, whitespace, encoding, timestamps, and environment-specific values before trusting the result.
  • Before sharing output, remove secrets, tokens, cookies, customer data, and production hostnames that are not needed for the review.

Next useful steps