Skip to content
LocalOnly

JSONPath Evaluator

Stable

Query JSON with JSONPath expressions and see live results.

Everything is processed locally in your browser

About JSONPath Evaluator

The JSONPath Evaluator lets you run JSONPath expressions against your document and see the matched results instantly. Test selectors, wildcards, array slices, and filter expressions to extract exactly the values you need. It is the ideal scratchpad for building and debugging the JSONPath queries you will use in code, tests, or tooling.

Features

  • Live evaluation as you type the expression
  • Supports wildcards, recursive descent, array slices, and unions
  • Filter expressions such as [?(@.price < 10)]
  • Shows each match along with its path in the document
  • Clear error messages for invalid expressions
  • Copy matched results as a JSON array

How to use JSONPath Evaluator

  1. 1

    Paste your JSON

    Add the document you want to query.

  2. 2

    Write a JSONPath expression

    Enter a selector like $.items[*].name to target values.

  3. 3

    See the matches

    Results update live, showing every matched value and its path.

  4. 4

    Copy the results

    Take the extracted values as a JSON array for use elsewhere.

Examples

Selecting nested authors

Extract every author from a list of books.

Input

{
  "store": {
    "book": [
      { "title": "A", "author": "Kay" },
      { "title": "B", "author": "Ng" }
    ]
  }
}

Output

// $.store.book[*].author
["Kay", "Ng"]

How JSONPath expressions work

JSONPath is a query language, not a property accessor

The difference that matters is that a query returns a set. `data.users[0].email` in JavaScript returns one value or throws. The JSONPath expression `$.users[*].email` returns every email in the array as a list, and returns an empty list rather than an error if there are none. That set-oriented behaviour is what makes it useful for extraction rather than navigation.

The syntax borrows deliberately from XPath. `$` is the root, `.` and `[...]` are child access, `*` is a wildcard, `..` is a recursive descent that searches every level, and `[?(...)]` is a filter expression. That vocabulary is small enough to learn in a sitting and expressive enough to cover most extraction tasks.

Recursive descent is the feature that earns its keep on unfamiliar data. `$..email` finds every `email` field anywhere in the document, at any depth, without you needing to know the structure. When you are exploring a response you did not design, that is often the fastest possible first query.

Filter expressions do the real work

Filters turn extraction into selection. `$.users[?(@.age > 30)]` returns only the matching users, where `@` refers to the element currently being tested. You can compare, combine with `&&` and `||`, and test for presence - `$.users[?(@.email)]` selects users that have an email field at all, which is a quick way to find incomplete records.

This is where JSONPath starts to overlap with what you might otherwise write as a loop, and for one-off inspection the query is usually faster to write and easier to adjust. The limits show up when you need aggregation - JSONPath can select the matching records but it cannot sum them, group them or sort them. At that point `jq` is the right tool.

Why the same query behaves differently in different tools

JSONPath was proposed in 2007 as a blog post rather than a standard, and implementations diverged for well over a decade. RFC 9535 finally standardised it in 2024, but most libraries in production predate that and each made its own decisions about the ambiguous corners.

The disagreements cluster in predictable places: whether a filter can call functions like `length()`, how slices with negative indices behave, whether parent access is supported, and whether a query returns paths as well as values. Union syntax and script expressions vary too.

The practical consequence is worth internalising: a query verified in one tool is not guaranteed to behave identically in another library. If a JSONPath expression is going into production code, test it against the specific library that will run it rather than trusting a web tool as the reference.

Reference

JSONPath syntax reference

ExpressionMeaningExample
$The root of the document$
$.keyA named child$.user
$['key']Bracket form, needed for keys with dots or spaces$['user.id']
$.a.bNested child access$.user.email
$[0]Array element by index$.users[0]
$[-1]Last element (widely but not universally supported)$.users[-1]
$[0:3]Slice from 0 up to but excluding 3$.users[0:3]
$.*Every child at this level$.users.*
$..keyRecursive descent - the key at any depth$..email
$[?(@.x > 1)]Filter on a condition$.users[?(@.age > 30)]
$[?(@.x)]Filter on presence of a field$.users[?(@.email)]
$[0,2]Union of specific indices$.users[0,2]

Which tool should you use?

These tasks overlap. Here is how to pick the right one for what you are actually doing.

You need a few fields out of a large response
This is the ideal case. One query beats scrolling, and it is reusable.
You do not yet know where a field lives
Use recursive descent: `$..fieldName` finds it at any depth without knowing the structure.
You need to sum, group or sort the results
JSONPath selects but does not aggregate. `jq` is the right tool for transformation and computation.
You want to browse rather than query
The JSON Tree Viewer is better when you do not yet know what you are looking for.

Use cases

  • Extracting a specific field from a large nested API response
  • Prototyping the JSONPath you will use in a config or pipeline
  • Filtering array items by a condition, such as price or status
  • Pulling all values at a given key regardless of depth
  • Debugging why a JSONPath selector returns no matches

Troubleshooting common errors

The query returns an empty result

Why: A path that matches nothing returns empty rather than erroring, so a typo looks identical to a genuine absence.

Fix: Shorten the query until it returns something, then extend it one segment at a time. That isolates the failing segment immediately.

A query that works elsewhere fails here, or vice versa

Why: Implementation divergence. JSONPath was only standardised as RFC 9535 in 2024 and libraries differ in the corners.

Fix: Test against the library you will actually deploy. Filters, negative indices and function calls are the usual points of disagreement.

A key containing a dot or a space cannot be reached

Why: Dot notation cannot express it - the dot is read as a separator.

Fix: Use bracket notation with quotes: `$['user.id']`.

You get one value where you expected a list

Why: An indexed access like `[0]` returns a single element; a wildcard or filter returns a set.

Fix: Use `[*]` or a filter expression to select multiple elements.

Limitations

What this tool deliberately does not do, so you know when to reach for something else.

  • JSONPath selects data but cannot transform, aggregate or reformat it - use `jq` for that.
  • Behaviour varies between libraries, since RFC 9535 postdates most implementations.
  • Filter expressions cannot reference the parent or the root in every implementation.
  • There is no way to reach a key containing a dot without bracket notation.
  • A non-matching query returns empty rather than reporting an error, so typos are silent.

Frequently asked questions

Related tools

JSON Tree Viewer

Explore JSON as a collapsible, interactive tree.

JSON Flattener

Flatten nested JSON into single-level dot-notation key paths.

Online JSON Formatter & Validator

Pretty-print JSON with configurable indentation and instant validation.

JSON Schema Validator

Validate JSON against a JSON Schema using AJV.

Learn more

How to Query JSON with JSONPath: A Practical GuideJSONPath lets you extract exactly the values you need from a JSON document without writing a parser. This guide covers the syntax and shows how to test expressions instantly.

Command Palette

Search for a tool or command