Data & Format / JSON Tools

JSONPath Tester

JSONPath Tester evaluates a JSONPath query against the JSON you paste and lists each match with the path that reached it. JSONPath became an official standard in 2024 as RFC 9535, but this page runs jsonpath-plus 10.4.0, which implements the earlier 2007 specification rather than the standard.

How to use

1
Paste the JSON you want to query
Paste any JSON document, or load the built-in sample if you only want to try the syntax. Queries run against whatever structure you supply, so starting from a real payload you already have is usually faster than inventing fixture data. Objects, arrays and top-level scalars are all accepted, and nothing you paste leaves the page.
2
Write an expression starting from the root
Every expression begins with $, the root of the document, and then walks down through child segments. $.store.book selects the book member inside store, $.store.book[0].title takes the first title, and $.store.book[*].title takes every title in the array. When you do not want to name the intermediate steps, $..title uses a descendant segment to search at every depth below the root.
3
Wrap filters in parentheses, not bare @
A filter selector applies to the children of the current node, with @ standing for the child being tested. The form that works here is the parenthesised one: $.store.book[?(@.price < 10)] keeps only the cheap entries. RFC 9535 also allows dropping the parentheses, as in [?@.price < 10], but this engine returns zero matches for that form without reporting an error — so if a filter you copied from the standard suddenly matches nothing, this is the first thing to check.
4
Read the value and the path together
Each match is reported twice: once as the value itself, once as the path that reached it. The path is the part you reuse — copying it into a second expression is how you build a query up step by step, and it is also the form you need when the same selection has to be expressed in code or in tooling that only understands JSON Pointer. Paths are printed in bracket notation, such as $["store"]["book"][0]["title"].
5
Copy the matches
Copy exports the matched values so they can go straight into a test fixture, a spreadsheet or a code generator. Evaluation happens entirely in the page, so a payload containing tokens or customer records never leaves your machine while you experiment with expressions.

Key facts

StandardJSONPath is specified in RFC 9535, published in February 2024 as an IETF Standards Track document and edited by Stefan Gössner, Glyn Normington and Carsten Bormann.Source:RFC 9535
Engine in useThis page evaluates queries with jsonpath-plus 10.4.0, which implements the original 2007 specification plus extensions such as ^ for parent and ~ for property names. Its own README states that the project is not actively maintained.Source:jsonpath-plus README
Function extensionsRFC 9535 defines exactly five function extensions — length(), count(), match(), search() and value(). None of them are available in this engine; using one raises a "not defined" error, so any expression relying on them needs a different engine.Source:RFC 9535 §2.4
Path output formatMatched paths are printed in bracket notation, for example $["store"]["book"][0]["title"]. That is this engine rendering, not a guaranteed interchange format — do not compare it byte for byte against the output of another library.Source:Measured with jsonpath-plus 10.4.0
HistoryJSONPath was introduced by Stefan Gössner in 2007 as a blog post modelled on XPath syntax. The standardised version arrived seventeen years later, by which point several incompatible dialects were already deployed in production tooling.Source:RFC 9535 §1.2

Frequently asked questions

Is JSONPath an official standard?

It became one in February 2024. RFC 9535, "JSONPath: Query Expressions for JSON", was published as an IETF Standards Track document with Stefan Gössner, Glyn Normington and Carsten Bormann as editors. Before that, JSONPath existed only as a 2007 blog post by Gössner and as a long series of competing partial implementations, which is why the same expression used to return different results in different libraries. RFC 9535 also specifies the normalised path format, and defines exactly five function extensions — length(), count(), match(), search() and value(). None of those five work on this page, and expressions that use them raise a "not defined" error rather than failing quietly.

Why does my result order differ from what another library returns?

Because object member order is not fully deterministic in the specification. RFC 9535 requires deterministic ordering for results drawn from arrays, but for results drawn from objects it explicitly allows implementations to return children in a non-deterministic order, and it allows a wildcard selector applied to an object to produce children in any order. Two fully conforming engines can therefore hand you the same set of matches in different sequences, and neither is wrong. If your downstream code depends on order, sort the results explicitly after the query instead of relying on the engine to hand them back in the sequence you saw in the document.

How do I select a parent or an ancestor?

You cannot, not in RFC 9535. The specification deliberately omits a parent selector: JSONPath is defined to walk downward from the root only, so there is no equivalent of the XPath parent axis. The jsonpath-plus engine behind this page does accept ^ as an extension for grabbing the parent, and the original 2007 draft used it too, but that syntax sits outside the standard and will not work in engines that follow RFC 9535 strictly. When you genuinely need to climb back up, select a wider subtree in one query and narrow the result in code afterwards — that keeps the expression portable, which matters as soon as it has to run somewhere other than a browser.

Can JSONPath replace jq?

Only partly, because they solve different problems. JSONPath is a selection language: given a document it returns the nodes that match an expression, and that is essentially all it does. jq is a transformation language with a full expression syntax, arithmetic, variable binding, user-defined functions and the ability to build entirely new documents. Any JSONPath expression has a direct equivalent in jq, but not the reverse. Reach for JSONPath when you need to point at part of a document — in a test assertion, an API gateway response mapping, or a monitoring rule — and reach for jq when you need to reshape data.

Is evaluating user-supplied expressions a risk?

Yes, and RFC 9535 devotes a security considerations section to exactly this. The realistic risk is resource exhaustion rather than code execution: a descendant segment combined with a filter can cause a single short expression to revisit the same subtree many times, so evaluation cost can grow quadratically with document size. That is harmless when the document is a few kilobytes and the expression is your own, and it becomes a denial-of-service vector when either input comes from an untrusted source. If you evaluate user-supplied queries server-side, cap both the document size and the evaluation time rather than trusting the expression to be reasonable.

Related tools

JSON Formatter

Paste JSON to pretty-print it with consistent indentation, minify it to one line, or find the exact line and column of a syntax error. Runs locally.

Query String to JSON

Convert a URL query string to JSON and back, preserving repeated keys as arrays and showing how plus signs and percent-encoding differ. Runs locally.