search

Found

info Overview

Merge a patch into a target JSON by RFC 7396 rules (null deletes, scalars replace, objects recurse) and trace each set, remove and root step.

📘 How to Use

  1. Paste the target JSON into the left box
  2. Paste the patch JSON (RFC 7396) into the right box
  3. Read the merged result and the operation trace

JSON Merge Patch (RFC 7396) Evaluator

JSON document that the patch is applied to.

null removes the member, scalar replaces, object recurses.

Status —
 
— 
—
Copied

    ※ Algorithm: if the patch is an object, recurse on each member; otherwise replace the target outright (RFC 7396 §2).

    ※ Arrays are treated as opaque values, so any array in the patch replaces the target array wholesale.

    grid_view Related

    Article

    JSON Merge Patch (RFC 7396) Evaluator | See the Merged Result and Every Operation

    Paste a target JSON and a patch JSON to apply the RFC 7396 merge rules, view the merged document, and read an ordered trace of every set, remove, and root-replace the patch triggered.

    💡 About this tool

    When you are building or reviewing an HTTP PATCH endpoint, you usually want to know what a given patch body actually does to the stored resource before you fire a real request. RFC 7396 (JSON Merge Patch) looks deceptively simple — you send a partial object and the server merges it in — but the corner cases bite: null deletes a member, missing keys stay untouched, nested objects recurse, and arrays are replaced wholesale instead of merged.

    This evaluator takes the guesswork out of it. Drop in the target and the patch, and it shows the merged JSON plus a numbered list of what changed: set /title = "Hello World", remove /author/email, and so on. That trace is the differentiator — instead of diffing two blobs by eye, you read the exact operations the merge produced, which makes it easy to confirm a PATCH spec does what you think and catch accidental wholesale replacements early.

    🧐 Frequently Asked Questions

    Q. How is this different from JSON Patch (RFC 6902)? RFC 6902 is an array of explicit operations — add, remove, replace, move, copy, test — and can target a specific array index. RFC 7396 is declarative: you send a partial object describing the desired state. It is more compact but cannot do partial array edits or set a value to null. This tool implements RFC 7396 only.

    Q. Can I patch a single element inside an array? No. Under RFC 7396 arrays are opaque values, so any array in the patch replaces the target array entirely. If you need element-level changes, that is a signal to reach for RFC 6902 instead.

    Q. What happens if I null out a key that the target does not have? Nothing. If the key is absent from the target, the null is a no-op — no removal happens and nothing is added to the trace.

    Q. What if the patch is a scalar or an array instead of an object? The whole patch replaces the target (RFC 7396 §2), and the trace shows a single "replace root" entry. An empty input box is treated as null.

    Q. Is key order preserved? The output is pretty-printed, so newly added keys may appear toward the end. RFC 7396 does not constrain key order, so compare results by semantic equivalence rather than byte-for-byte.

    📚 Why a trace matters

    Most merge-patch helpers just hand you the result document and leave you to diff it against the original. The trouble is that a merge can do something subtle — a nested object you expected to recurse instead got root-replaced because the target value was not an object — and a raw result hides that. Exposing the ordered operations turns the merge into something you can audit line by line. RFC 7396 also ships its own media type, application/merge-patch+json, which is how an HTTP server distinguishes "treat this body as a merge patch" from a plain PUT-style replacement — a detail worth checking when your PATCH route silently overwrites fields you expected to keep.