JSONPath shows up in error messages, in API documentation, in JSON Schema validation output, and in query tools like jq - usually with no explanation, on the assumption you already know what $.users[3].address.city means. If you don’t, it looks like a small piece of code rather than what it actually is: a plain-text address for one specific value inside a JSON document.
Reading JSONPath syntax
JSONPath describes a route from the root of a document down to a single value, the same way a file path describes a route from a drive letter down to a single file. A few symbols do all the work:
$- the root of the document. Every JSONPath starts here..key- “go into the object’s field namedkey.”$.namemeans “thenamefield at the top level.”[n]- “go into the array at indexn” (zero-based, so the first element is[0]).- Chaining these together walks deeper:
$.users[3].address.cityreads as “start at the root, go intousers, take the 4th element (index 3), go into itsaddressfield, then itscityfield.”
That’s the core of it. Some tools support extra syntax on top - wildcards (*), filters ([?(@.age > 30)]), recursive descent (..) - but the dotted-path-plus-array-index form above covers the large majority of real usage, including “copy this value’s path” features in JSON viewers.
What it’s actually for
JSONPath is most useful as a precise, unambiguous way to refer to one value in conversation with a tool, a script, or another person - three concrete cases come up constantly:
Bug reports. “The city field is wrong” is ambiguous the moment a document has more than one city field at different nesting levels. “$.users[3].address.city is wrong” points at exactly one value with no room for misreading.
Scripts and queries. Tools like jq, JSON Schema validators, and many logging/observability platforms accept JSONPath-like expressions to extract or filter on a specific field, without you having to write a full parsing script for a one-off lookup.
API documentation and error messages. A validation error that says the problem is at $.items[12].price tells you exactly where to look, rather than “some field somewhere in the items array.”
Getting the path without counting brackets by hand
Writing out a JSONPath by hand means carefully counting array indices and nesting levels - tedious and easy to get wrong on anything past a couple of levels deep, especially inside a long array. The faster way is to let a tool that already understands the document’s structure generate it for you: click any value in Jsontify’s tree viewer and its JSONPath appears in the Inspector panel, ready to copy, computed directly from wherever you clicked rather than typed out by hand.
This works the same way regardless of how deeply nested the value is or how large the surrounding document is - the tree view and the JSONPath it generates are both built to handle large, deeply nested documents without needing to fully expand every branch first to find what you’re looking for. Everything runs in your browser - nothing is uploaded to our servers to compute a path or search the document.
A quick reference
| Syntax | Meaning |
|---|---|
$ | The root of the document |
.key | A named field of an object |
[n] | The element at index n of an array |
$.a.b[0].c | Root -> field a -> field b -> first array element -> field c |
Once you can read that table, most JSONPath expressions you run into - in error messages, in jq one-liners, in a colleague’s bug report - stop looking like code and start looking like what they are: directions to one specific value.