99tools

JSONPath Tester

runs in your browser

Run a JSONPath query against your JSON and see every match with the path that reached it. Says where a broken expression went wrong, not just that nothing hit.

JSON

584 chars

Matches

2 matches

  1. $.store.book[0].title

    "Sayings of the Century"

  2. $.store.book[2].title

    "Moby Dick"

What this understands

the whole of it
the document itself
a named child
the same, for keys with dots or spaces
several named children at once
one element, counting from zero
counting back from the end
several elements
a slice, end exclusive
a slice with a step
every element
every author at any depth
a filter: <, >, <= and >= too
an exact value, or != for not
a regular-expression match
only those that have an isbn

about this tool

Query, and see where each match lives

Paste JSON, write a path, and every match appears with the exact location that reached it. The path matters as much as the value: $..book[?(@.price < 10)] tells you which books are cheap, but $.store.book[0] is what you write in your code. Every path shown is one you can paste back into the box to get that single value on its own.

An empty result is not an error

The two questions someone testing a path actually has are "does this match what I think" and "did I get the syntax wrong" — and most tools answer both with an empty list.

Here they are different answers. A valid path that finds nothing says exactly that. A broken one gives the reason and the place it gave up: an unclosed bracket, a bare word where an index belongs, a filter that forgot its @. Where a message can show the shape you were reaching for, it does.

That is the reason this evaluator is written rather than borrowed. A library returns matches; only something that owns the parser can explain a mistake.

The syntax, all of it

Listed on the page under what this understands, and clickable — press one to try it against the sample. Children and quoted names, indexes including negative ones, index lists, slices with a step, wildcards, recursive descent with .., and filters comparing @ to a value.

Nothing is left off the list. A query language with an undocumented subset is worse than no query language, because you cannot tell a missing feature from a typo.

Slices behave the way Python's do — end exclusive, negative bounds counting from the end, a negative step walking backwards — because that is what people expect of [1:3].

Nothing leaves your browser

The parsing and the evaluation both run in this page. Nothing is uploaded and nothing is stored, which matters for the API responses people usually paste in here.

To look at the shape of a document rather than query it, use the JSON tree viewer. To tidy it first, use the JSON formatter.

questions

Why does it show a path next to every match?
Because the path is usually what you came for. A query like $..book[?(@.price < 10)] tells you which books are cheap, but $.store.book[0] is what you put in your code. Every path shown is one you can paste straight back into the box to get that single value.
My expression matches nothing. Is it wrong?
The tool tells you which. A valid path that finds nothing says so plainly; a broken one gives you the reason and where it gave up. Telling those two apart is most of what testing a path is for, and it is why this evaluator is written here rather than borrowed.
Which syntax is supported?
All of it is listed on the page, under "what this understands": children, quoted names, indexes, negative indexes, index lists, slices with a step, wildcards, recursive descent, and filters with <, >, <=, >=, ==, != and a regular-expression match. Click any of them to try it. A query language with an undocumented subset is worse than none.
Does my JSON get uploaded?
No. The parser and the evaluator both run in this page, so nothing is sent anywhere and nothing is stored.
Why is <= not read as <?
Because the comparison operators are matched longest-first. It sounds obvious, and it is the bug most hand-written JSONPath implementations ship with, so there is a test for it.