Fast, practical, browser-based developer tools
Query JSON using simple path expressions like user.profile.name or
items[0].id. This tool helps you inspect nested values quickly when working
with API responses, configuration files, test payloads, mock data, and structured JSON.
Large JSON responses can be difficult to inspect manually, especially when they contain nested objects and arrays. A JSON path evaluator helps you jump directly to the value you need instead of opening every level by hand. This is useful for debugging APIs, testing payloads, checking structured data, and exploring JSON responses more efficiently.
This JSON path tool is designed to work directly in the browser. That means the JSON text you paste and the path expression you evaluate are processed locally on your device during normal use instead of being uploaded as part of the tool’s main workflow.
For more details about site usage and analytics, read our Privacy Policy.
Paste your JSON into the input area, enter a path expression, and click Evaluate Path. The tool will try to resolve the path and return the matching value in formatted JSON. You can then copy the result or download it as a file.
user.profile.city or items[0].name.{
"user": {
"profile": {
"name": "John",
"city": "London"
}
},
"items": [
{ "id": 1, "name": "Book" },
{ "id": 2, "name": "Pen" }
]
}
Path: user.profile.city Result: "London"
Unlike JSON itself, JSONPath spent most of its life with no formal specification. It began as a 2007 blog post by Stefan Gössner that sketched a syntax by analogy with XPath, and dozens of libraries then implemented it slightly differently. The consequence is real and still with us: the same expression can return different results in different tools. How recursive descent behaves, whether a result is wrapped in a list, how a filter is written, what happens on a missing path — implementations disagreed on all of it.
That gap finally closed with RFC 9535, published in February 2024, which standardises the syntax and semantics after seventeen years. It is worth knowing which you are dealing with: a library written before 2024, or one that has not adopted the RFC, may not match the standard's behaviour on edge cases even though simple queries look identical.
This tool handles the common navigation cases: dot notation like
user.profile.name and array indexing like items[0].id. That
covers most day-to-day "reach into a response and grab one field" tasks. It is deliberately
a straightforward path lookup, not a full RFC 9535 engine.
So the more powerful JSONPath operators — recursive descent .., the wildcard
*, array slices like [0:3], and filter expressions such as
[?(@.price<10)] — are outside this tool's scope. If a query using those
returns nothing here, that is the reason. The next section explains what they do so you can
recognise when you need a full implementation.
Three constructs are what make full JSONPath powerful. Recursive descent,
written .., searches every level of the document, so $..price
collects every price field no matter how deeply it is nested — the feature
people most often reach for and most often miss in a simple evaluator. The
wildcard * matches all children of a node, as in
$.items[*].id.
Filter expressions select by predicate. $.items[?(@.stock==0)]
returns only the elements whose stock is zero, where @ refers to
the current element being tested. These are what turn JSONPath from a navigation shorthand
into a query language, and they are exactly the parts that historically varied most between
implementations — another reason RFC 9535 matters.
JSONPath borrows its shape from XPath but works on a data model with no attributes,
namespaces, or element order to worry about. Two symbols do the heavy lifting:
$ is the root of the document and @ is the current node inside a
filter. A subtle but important point from the standard is that a query yields a
nodelist — a list of every match — even when there is exactly one, so
calling code should expect a collection rather than a single value.
A path that matches nothing returns an empty result, not an error and not
null. That distinction matters when you test for existence: an empty result
means "no such node", which is different from a node that exists and holds the value
null.
Now, yes — RFC 9535 standardised it in February 2024. For the seventeen years before that it was only an informal 2007 blog post, which is why older libraries implemented it inconsistently and can still disagree on edge cases.
Because implementations diverged before RFC 9535. Recursive descent, filters, result wrapping, and missing-path handling were never uniformly defined, so a query that works in one library may return a different shape — or nothing — in another.
Dot notation like user.profile.name and array indexing like
items[0].id. It is a simple lookup, so recursive descent
.., wildcards *, slices, and filter expressions are not
supported here.
.. operator do?
Recursive descent. $..price finds every price field at any
depth in the document, rather than a single fixed path. It is the most commonly needed
feature that a basic evaluator lacks.
They select elements by predicate. $.items[?(@.stock==0)] returns only the
items whose stock is zero, with @ standing for the element
being tested. Filters are the part of JSONPath that varied most between older
libraries.
By design. RFC 9535 defines a query result as a nodelist — every match in order — even
when there is exactly one, so treat the output as a collection. A path that matches
nothing gives an empty list, which is distinct from a value that is genuinely
null.