JSONPath expressions are compact, which makes them easy to write slightly wrong and hard to debug by reading alone. A single field name typo, a bracket in the wrong place, or a filter that should have matched three items but matched zero, are all common mistakes that only become obvious once you actually run the expression against real data and look at what comes back.
This tool implements a clearly scoped, documented subset of JSONPath syntax rather than the full, informally specified language that has accumulated years of competing extensions across different libraries. The supported syntax is listed explicitly on this page and in the tool interface, so you always know exactly what will and will not be evaluated before you rely on an expression in real code. Use it as a json path evaluator during development, or simply to test jsonpath expression syntax before pasting it into an application that has no visible feedback of its own.
Exactly which JSONPath syntax this jsonpath tester supports
Because JSONPath was never formalised the way JSON itself was for most of its existence, different implementations disagree on the more advanced parts of the syntax, particularly filter expressions and script evaluation. Rather than guess at compatibility with every library, this tool supports a specific, clearly bounded subset chosen because it covers the overwhelming majority of real world lookups: reading a field, indexing into an array, and wildcarding across every element of an array or object.
Recursive descent, written as two dots such as $..price, is deliberately out of scope for this evaluator. It is one of the more inconsistently implemented parts of JSONPath across different libraries, and supporting it properly means walking the entire document tree at every level rather than following an explicit path, which is a meaningfully different kind of query than the rest of what this tool supports.
- $ refers to the root of the document.
- .field or ['field'] accesses a named property of an object.
- [n] accesses a zero based index of an array.
- [*] matches every element of an array, or every value of an object.
- Segments can be chained, such as $.store.books[*].title or $.users[2].address.city.
Why recursive descent is out of scope for this JSONPath syntax checker
The two dot recursive descent operator asks for every matching field anywhere in the document, regardless of depth, which is powerful but also the single feature most responsible for JSONPath implementations disagreeing with each other on edge cases like array handling and ordering. Different libraries return matches in different orders, handle a mix of arrays and objects at the same depth differently, and disagree on whether the root itself counts as a match.
Supporting a documented, unambiguous subset well was judged more useful than supporting every advertised feature inconsistently. If your expression needs recursive descent, this jsonpath tester will tell you clearly that the syntax is unsupported rather than silently returning an incomplete or wrong result, which is the outcome that actually wastes debugging time.
Reading the results of a jsonpath query online
Every match is shown with the concrete path that produced it, written out in full, such as $.store.books[1].title, so when an expression using a wildcard matches several values you can see exactly which element of the array or object each one came from rather than a flat list of values with no context.
A query that matches nothing is reported as zero matches rather than an error, because an empty result from a path that legitimately does not exist in this particular document is a valid, expected outcome, not a failure of the tester itself. The distinction between a syntax error in your expression and a correctly evaluated expression that found nothing is shown clearly so you know which one you are looking at.
Common mistakes this JSONPath expression tester catches
Bracket notation and dot notation are not interchangeable when a key contains characters outside a plain identifier. A key like item-count or a key that starts with a digit has to be written as ['item-count'] because dot notation only accepts identifier style names, and using a dot with a hyphenated key is a common source of an expression that looks reasonable but matches nothing.
Array indices are zero based, matching how arrays work in JSON itself and in most programming languages, so the first element of a books array is books[0], not books[1]. Writing a one based index against a real array is one of the most frequent single character mistakes people bring to this tool.
Mixing up dot access on an array with bracket index access on an array is another common error. $.books.title tries to read a title property directly on the array itself, which does not exist, where $.books[*].title correctly reads the title from every element inside it.
How this JSONPath tester evaluates an expression
The expression you type is first tokenised into a sequence of segments, root, field access, index access or wildcard, using a small parser rather than a single large regular expression, because a regular expression alone cannot correctly track nested brackets and quoted strings the way a segment aware parser can.
Each segment is then applied in order against the current set of matched values, starting from the whole document at the root and narrowing down one step at a time, exactly the way the path reads left to right. This step by step evaluation is also why the tool can show you the concrete path for every match, since it already knows precisely which segment produced which value at each stage.
| Syntax | Meaning | Example |
|---|---|---|
| $ | The root of the document | $ |
| .field | Access a named property | $.store.name |
| ['field'] | Access a property by quoted name | $.store['item-count'] |
| [n] | Access a zero based array index | $.books[0] |
| [*] | Match every element or value | $.books[*].title |
| ..field | Recursive descent, not supported | not evaluated |
How to use the JSONPath tester
- 1
Paste your JSON document
Add a real JSON sample into the input box, or drop a .json file. Nothing is uploaded.
- 2
Write a JSONPath expression
Start with $ and add field, index or wildcard segments, such as $.store.books[*].title.
- 3
Run the expression
Press evaluate to run the query against your document using the supported syntax subset.
- 4
Review each match and its path
Check the value and the exact concrete path shown for every match, and adjust the expression if the count is not what you expected.
Related tools worth bookmarking
Sources and further reading
- RFC 9535: JSONPath Query ExpressionsThe IETF standard formally defining JSONPath syntax, including the segments this tester implements.rfc-editor.org
- IETF RFC 8259: The JSON Data Interchange FormatThe specification defining the JSON documents that a JSONPath expression is evaluated against.ietf.org
- JSON.org: Introducing JSONThe plain language description of JSON's object, array and value types referenced throughout this tool.json.org
Frequently asked questions
Common questions about the jsonpath tester.
No, and this is a deliberate scope decision rather than an oversight. Recursive descent is one of the most inconsistently implemented parts of JSONPath across different libraries, so this tool supports a documented, unambiguous subset instead: root access, field access, array indexing and wildcards, all clearly listed on this page.
The most common causes are a field name typo, a one based index used against a zero based array, or dot notation used on a key containing a hyphen or a leading digit, which needs bracket notation with quotes instead. Check the supported syntax list and try narrowing the expression one segment at a time.
No. Your expression is tokenised into segments, and each one is applied against the parsed document by a small evaluator written in JavaScript that runs entirely in the tab. Production data pasted in to test a path is never serialised into a request just to check the match.
Yes. A wildcard segment such as $.config[*] matches every value of an object the same way it matches every element of an array, since both are treated as collections of values to iterate over once the wildcard segment is reached.
Dot notation such as .name only works for keys that look like a plain identifier, letters, digits and underscores with no leading digit. Bracket notation with quotes, such as ['item-count'], works for any key at all, including ones with hyphens, spaces or a leading digit, which is why it exists as an alternative rather than a stylistic choice.
JSON Pointer, defined in RFC 6901, addresses exactly one location using a simple slash separated path with no wildcards or arrays of matches. JSONPath can return several matches at once through wildcards, which is what a jsonpath tester like this one is built around, and the two are not interchangeable syntax for the same underlying idea.