Once a JSON document has more than a few levels of nesting, writing code to walk down to one specific value gets tedious fast — a chain of obj.store.book[2].author that breaks the moment a field is missing. JSONPath is a query language built to skip that: one string that reaches directly into a document and pulls out exactly the value (or values) you want.
The short definition
JSONPath is a query language for selecting nodes out of a JSON document — XPath's equivalent for JSON, where XPath navigates XML. An expression like $.store.book[*].author reads left to right, root to leaf, the same way the document is nested, and can express things a plain property chain can't: every item in an array, every value at any depth, or only the items matching a condition.
Where it came from
Stefan Gössner published the original JSONPath proposal in a 2007 blog post, explicitly modeled on XPath. It was never an official standard at the time — just a specification popular enough that roughly 50 independent implementations sprang up across different languages, and, predictably, drifted apart on edge cases as each one filled in gaps the original post left open. That changed in 2024, when RFC 9535 formally standardized JSONPath's syntax and semantics — seventeen years after the original post. Most JSONPath libraries in wide use today, including the one behind this site's own tools, predate the RFC and implement the original Gössner-style syntax plus their own extensions, so exact behavior on an unusual expression can still vary between tools.
The syntax, briefly
$ is the root of the document, .key steps into a property, [n] indexes an array, * matches everything at that level, and .. searches recursively at any depth — $..price finds every price field in the whole document, no matter how deep. Filter expressions like [?(@.price<20)] keep only the elements matching a condition, where @ refers to the element currently being tested. The full reference, with every operator and live examples, is in JSONPath Tester's syntax table.
JSONPath vs. JSON Pointer vs. JMESPath vs. jq
Several tools solve a similar problem with different amounts of power, and it's easy to reach for the wrong one by name alone:
- JSON Pointer (RFC 6901) — the simplest of the four: one exact path to one location, like
/store/book/0/author. No wildcards, no filters, no "every item matching X." This is what a JSON Schema$refuses internally, and what this site's JSONPath Generator also shows alongside each JSONPath expression it produces. - JMESPath — a separate query language, not a JSONPath variant, despite the similar-looking name and purpose. It's what AWS CLI's
--queryflag actually uses, with built-in functions for filtering and reshaping data as part of the query itself. - jq — a full command-line JSON processor, not just a query language; it can transform, combine, and reshape data, well beyond "select this value." Reach for it once the task outgrows "pull a value out" into "restructure this into something else."
kubectl get pods -o jsonpath='{.items[*].metadata.name}' uses actual JSONPath; the visually similar aws ... --query does not — a common mix-up if you work with both CLIs regularly.
A security note on script expressions
Gössner's original syntax and several popular libraries support script expressions — a parenthesized snippet like [(@.length-1)] evaluated against the current node. Early implementations of this literally ran the snippet through JavaScript's eval(), which is a textbook injection risk if the expression (or the data it operates on) comes from somewhere untrusted — a real, disclosed vulnerability class in at least one popular library. Modern libraries default to a safer mode that parses these expressions with a minimal evaluator instead of real eval()/Function() — the default this site's own JSONPath Tester and JSONPath Generator run with. If you're embedding a JSONPath library server-side against expressions you don't control, confirm which mode it defaults to before trusting it with untrusted input.
Try it yourself
Type an expression against real JSON and see every match update live with JSONPath Tester, or go the other direction — click a key or value in a document to get the expression that reaches it — with JSONPath Generator. Both run entirely in your browser.