JSONPath Tester Online
This tool answers one question about a JSON document: which values sit at the location an expression describes. Paste the document, write the expression, and the result panel lists each match with the path where it was found and the value itself, keeping the original types - a price stays a number, a nested object stays an object, a boolean stays a boolean.
It is built for the moments when reading the document by eye stops working: an API response several levels deep where you only need the ids, a configuration file where one field is nested somewhere unpredictable, a log payload you want to reduce to the handful of fields that matter, or an expression copied from a colleague that you need to confirm behaves the way they said it does.
Every result on this page - and every result in the panel above - is produced by the same engine, so the documentation can never describe an outcome the tool does not actually give.
How to Test a JSONPath Expression
The whole workflow is five steps, and both fields start already filled with an example so the first press shows a real result.
- Paste the JSON document you want to query into the JSON panel.
- Type the expression in the JSONPath field, starting with $ for the root of the document.
- Press Enter, or click Test JSONPath, to run it.
- Read the result: every match lists the path it was found at and the value itself, with its original JSON type.
- Change the expression and test again - a wildcard, an index, a slice or a filter each answer a different question about the same document.
Both fields start already filled in, so the first press of Test JSONPath shows real matches before you replace either one with your own.
Example: every title in a nested array
The document below holds a store with an array of books. The expression walks to the array and takes the title of each item with the wildcard:
{
"store": {
"book": [
{ "category": "fiction", "title": "The Hobbit", "price": 12.99 },
{ "category": "programming", "title": "Clean Code", "price": 29.99 }
]
}
}$.store.book[*].title2 matches, each with the path it was found at.
$.store.book[0].title"The Hobbit"$.store.book[1].title"Clean Code"
Example: searching the whole document
Recursive descent starts at the root and collects the named property from every node it reaches, so the depth of the document does not have to be known in advance:
{
"store": {
"book": [
{ "category": "fiction", "title": "The Hobbit", "price": 12.99 },
{ "category": "programming", "title": "Clean Code", "price": 29.99 }
]
}
}$..price2 matches, each with the path it was found at.
$.store.book[0].price12.99$.store.book[1].price29.99
Example: filtering on a value
A filter keeps the items for which an expression is true. Here only the books under twenty are kept, and then only their titles:
{
"store": {
"book": [
{ "category": "fiction", "title": "The Hobbit", "price": 12.99 },
{ "category": "programming", "title": "Clean Code", "price": 29.99 }
]
}
}$.store.book[?(@.price < 20)].title1 match, reported with the path it was found at.
$.store.book[0].title"The Hobbit"
Example: a valid expression that matches nothing
The store has no magazine property. The expression is perfectly well formed, so the answer is an empty result and not an error:
{
"store": {
"book": [
{ "category": "fiction", "title": "The Hobbit", "price": 12.99 },
{ "category": "programming", "title": "Clean Code", "price": 29.99 }
]
}
}$.store.magazineThe document parsed and the expression is valid - it simply matched nothing. An empty result like this is a normal answer, not an error.
Example: an expression that does not parse
An unclosed bracket is a different failure entirely. Nothing is evaluated, and the column where the parser stopped is reported instead:
{
"store": {
"book": [
{ "category": "fiction", "title": "The Hobbit", "price": 12.99 },
{ "category": "programming", "title": "Clean Code", "price": 29.99 }
]
}
}$.store.book[0Expected "]" but found end of input.
The parser stopped at column 15. The document is fine; only the expression needs fixing.
$.store.book[0The last three outcomes look similar in a result panel - all three show no values - but they mean three different things, which is why they are worded separately here and in the tool.
JSONPath Syntax Reference
This table is the single source of truth for what the tool accepts: every row below is implemented, and nothing is advertised twice or left unimplemented.
| Expression | Meaning |
|---|---|
$ | The root of the document. On its own it matches the whole JSON value. |
.name | The property name of an object. A property that does not exist matches nothing. |
['name'] | Bracket notation for names dot notation cannot write, such as names with spaces or dots. Both single and double quotes are accepted. |
[0] | The array item at index 0. A negative index counts from the end, so [-1] is the last item. An index past the end matches nothing. |
[*] | Every item of an array, or every property value of an object. Written as .* it does the same after a dot. |
..name | Recursive descent: the property name of the node the expression has reached and of every node inside it, at any depth. |
..* | Every property value and array item in the document, at any depth. |
[1:3] | An array slice, from index 1 up to but not including index 3. [start:end:step] is accepted too, and negative numbers count from the end. |
[0,2] | A union: index 0 and index 2. Quoted names union the same way, as in ['title','price']. |
[?(@.price < 10)] | A filter that keeps the array items - or the object values - for which the expression is true. == != < <= > >= && || ! and parentheses are supported, with @ for the item being tested and $ for the root. |
Script expressions [( ... )], regular-expression matching and a length shortcut are not part of this implementation: the first two are reported as an expression error rather than guessed at, and a property that simply is not in the document matches nothing.
What Is JSONPath?
JSONPath is a query language for JSON, deliberately small. Where JSON describes data, JSONPath describes where data sits: one expression names a location in the structure and the engine returns every value living there. It does not change the document, it does not format it and it does not execute anything - it only selects.
The closest everyday comparison is a file path. $ is the root directory, .name descends into a folder, [0] picks a file by position, [*] takes them all and ..name searches every subdirectory. The difference is that JSON documents are nested data rather than a flat tree, so an expression can also filter on the values it finds and slice a run of array items.
JSONPath is not one formal specification - several dialects exist and they disagree in small ways - which is exactly why a tester is useful: you can confirm that the dialect you are writing in is the dialect the tool you are about to use implements, before a pipeline depends on it.
Common JSONPath Mistakes
Most expressions that do not return what you expect fall into one of these. Each one is fixable in the expression field without touching the document.
The expression does not start with $
Every expression begins at the root of the document, and the root is written $. Writing .store.book selects a property of nothing, so nothing matches. Prefix it: $.store.book.
A property name needs brackets, not dots
Dot notation cannot write a name that holds a space, a dot or another character JSONPath reserves. Use bracket notation with quotes for those, as in $['user name'] or $["v1.2"].
Array indexes start at zero
[1] is the second item, not the first, and an index past the end of the array matches nothing rather than clamping to the last item. A negative index counts from the end, so [-1] is the last item.
A missing property matches nothing instead of failing
This is deliberate. An expression that is well formed but selects an absent name returns an empty result, which is different from an expression that does not parse. The tool reports the two separately so a typo in the document is not confused with a typo in the expression.
Property names are case sensitive
$.title will not match a property written "Title". JSON is case sensitive, so the expression has to match the document exactly, character for character.
Filter expressions compare against @, not the root
Inside [?( ... )] the item being tested is @, so [?(@.price < 10)] keeps the books under ten. The root of the document is still available as $, which is what makes [?(@.price < $.budget)] possible. Values compared with a number must be unquoted; strings need quotes.
A script expression is reported as an error
Goessner-style script expressions written as [( ... )], regular-expression matching and a length shortcut are not part of this implementation. Rather than guessing at what they meant, the parser stops and reports the column it stopped at, so an unsupported expression can never be mistaken for one that simply matched nothing.
One case sits outside that list because it happens before the expression is read at all: a document that is not well-formed JSON is reported as a syntax error with its line and column, and the expression is not evaluated. When that happens, fix the document first - the JSON Validator will tell you exactly where it stopped parsing.
Frequently Asked Questions
What is a JSONPath expression?
A JSONPath expression is a short string that describes where a value sits inside a JSON document, in much the same way an XPath expression points at a node in XML or a file path points at a file on disk. $ is the root of the document, .name steps into a property, [0] takes an array item, [*] takes everything, and ..name searches the whole tree. Written well, one line can pick every price out of a nested payload.
How do I test a JSONPath expression online?
Paste the JSON you want to query into the JSON panel, type the expression into the JSONPath field, and press Enter or click Test JSONPath. The result panel lists every match with the path it was found at and the value itself, keeping the original JSON types - a number stays a number and an object stays an object. Ctrl+Enter runs the same test from anywhere on the page.
What is the difference between a JSONPath result and a JSON path in an error message?
They are the same idea used for two different jobs. The path inside an API error message tells you where in the document the problem is, and it is written for you to read. A JSONPath expression is written by you to ask the document a question. This tool is for the second case: it evaluates what you write and shows you what came back.
Why does my JSONPath return no results?
Usually one of a handful of reasons: the expression is missing its leading $, a property name is spelled or cased differently from the document, an array index is past the end, or the value genuinely is not there. The tool reports a valid expression that matched nothing as its own outcome - an empty result with an explanation - which is separate from an expression that does not parse, so you always know which of the two you are holding.
Why is my JSONPath expression reported as invalid?
The parser stopped at a specific column, and the panel shows that column with a caret underneath it. Common causes are an unclosed bracket, a stray quote inside a union, a filter that is not closed with )], or syntax from outside this implementation such as a script expression written as [( ... )]. The JSON panel is untouched when this happens, so the document is not the problem.
Which JSONPath syntax does this tester support?
It supports $, .name, ['name'], [0], negative indexes, [*], ..name, ..*, slices, unions and [?( ... )] filters. That covers the Goessner-style dialect documented at jsonpath.com. Script expressions [( ... )], regular-expression matching and a length shortcut are not part of this implementation: the first two are reported as an expression error rather than guessed at, and a property that simply is not in the document matches nothing.
Is JSONPath the same as a regular expression?
No. A regular expression matches characters in a string and has no knowledge of structure. JSONPath walks the structure of a parsed document - objects, arrays and values - so it can say which property an item belongs to and can return a whole subtree rather than a slice of text. The result of JSONPath is real JSON, not a rewritten string.
Is my JSON uploaded anywhere?
No. Parsing and evaluation both happen in your browser, in the page you are looking at. Nothing is sent to a server, no account is needed, and the expression is read by a parser rather than executed as code, so an expression can only read the document it is given.
What to do after testing an expression
Once an expression returns what you expect, the usual next steps are the ones around it in a JSON workflow. JSON Tree Viewer shows the same structure as collapsible nodes when you want to see where a value lives before writing the expression, and JSON Flattener turns every path in a document into a single key, which is often the quickest way to see which paths are available to query.