JSONPath & JMESPath Tester — Query JSON Online

Query a JSON document without writing a program

Sooner or later every JSON document turns into a question. Which line items have a quantity above one? What are all the prices, wherever they appear? What does this API return once you strip it down to the three fields you actually need? Writing a script to answer that is possible but wasteful, and eyeballing a 4,000-line response is worse. A path expression answers it in one line — the trick is getting the line right, which is what this page is for.

It runs two dialects. JSONPath, evaluated by jsonpath-plus, is the XPath-inspired notation you already meet in Postman tests, log pipelines, API gateways and a hundred config formats: it starts at the root, walks down through keys and array indices, and can search recursively for a key at any depth. JMESPath, the language behind the AWS CLI's --query, Ansible's json_query and the Azure CLI, is a small expression language: it evaluates to exactly one value, and it can reshape what it selects into a new object.

Both evaluate against the document in the large pane, with the expression in the smaller pane below it, the moment you press Run query. Results come back as pretty-printed JSON at your chosen indentation, ready to copy into a test, a fixture or a ticket. If the expression will not parse, the engine's own message is shown verbatim rather than being rewritten into something vaguer — library messages are terse but they are precise about where the parser gave up.

Everything runs locally. The engines are fetched to your browser and evaluated there, so you can test against a genuine production response — tokens, customer names and all — without it being uploaded anywhere. When you need to understand the structure first, open the payload in the JSON Viewer or tidy it in the JSON Formatter, then come back and write the expression against the real shape.

JSONPath vs JMESPath, task by task

The two dialects overlap for simple lookups and diverge sharply once you ask for anything clever. The table below maps the tasks that come up daily onto both notations, using the sample order document loaded by the Sample button — an order with a customer object and an items array.

Three differences do most of the damage when you switch between them. Literals: JMESPath requires backticks around numbers and JSON literals inside filters, so [?qty>`1`] is right and [?qty>1] is a parse error, while JSONPath writes it plainly as [?(@.qty>1)]. Roots: JSONPath expressions conventionally begin with $, JMESPath expressions simply begin with the first key. And depth: JSONPath's .. searches every level for a key, which JMESPath deliberately has no equivalent for — if you do not know where a value lives, JSONPath is the only one of the two that can find it.

The other asymmetry is direction. JSONPath only ever gives you back nodes that already exist in the document, flattened into a list. JMESPath can construct: rename keys, pick a subset, build a hash per element, apply functions such as length(), sort_by() and join(). If your goal is "find it", start with JSONPath; if your goal is "give me this shape", start with JMESPath.

Worked example: the same question, both ways

The Sample button loads the order below: a couple of top-level fields, a customer object, and two line items with a SKU, a quantity and a price. It is deliberately small enough to check the answers by eye, and shaped like the payloads that actually cause trouble — an array of objects nested inside a document.

Ask JSONPath for the SKUs of every line item ordered more than once — $.items[?(@.qty>1)].sku — and it filters the array, then pulls one field from each survivor. The result is a flat array of matches, wrapped as always, so a second qualifying item would simply appear as a second element.

Ask JMESPath the same question but demand a shape — items[?qty>`1`].{sku: sku, qty: qty} — and it filters with backticked literals, then builds a fresh object per surviving element containing only the keys you named. Note that the quantity comes along for the ride, which JSONPath cannot do in one expression: it would have to return the whole object and let you throw away the parts you did not want.

That is the practical distinction in one example. JSONPath extracts values that exist; JMESPath produces the structure you asked for. Both answers are correct; which one you want depends on whether the next step is a human reading it or a program consuming it.

{
  "orderId": "ORD-10428",
  "status": "paid",
  "total": 48.5,
  "customer": {
    "name": "Ada Lovelace",
    "email": "ada@example.com"
  },
  "items": [
    {
      "sku": "TS-BLK-M",
      "qty": 2,
      "price": 18
    },
    {
      "sku": "MUG-01",
      "qty": 1,
      "price": 12.5
    }
  ]
}

[
  "TS-BLK-M"
]

[
  {
    "sku": "TS-BLK-M",
    "qty": 2
  }
]