JSONPath Tester: Query and Extract Data from JSON Instantly

JSONPath is a query language for pulling specific values out of a JSON document without writing a loop, an.filter(), or a chain of optional-chaining lookups to get there. Instead of walking a response by hand — data.users[2].address.city and hoping index 2is still the right one next time the API returns data — you write one expression that describes the shape of what you're looking for, and a JSONPath evaluator returns every node in the document that matches it. That matters most on documents you don't fully control the shape of: a third-party API response, a large generated config file, a log line dumped as JSON. Before an expression can match anything, the document has to actually be valid JSON — if you're starting from a raw paste that hasn't been checked or pretty-printed yet, the JSON Formatter guide covers validating and formatting it first.

Every JSONPath expression starts at $, the root of the document, and narrows from there with a small set of operators:

• . — child access by key, e.g. $.user.name.
• [] — bracket access, for keys that aren't valid identifiers or for array indices, e.g. $.users[0] or $["user-id"].
• * — the wildcard, matching every child of the current node regardless of key or index, e.g. $.users[*].namefor every user's name.
• .. — recursive descent, searching every level of the document below the current node instead of just the immediate children, e.g. $..email to find an email field wherever it appears, at any depth.
• [?(@.field==value)] — a filter expression, keeping only the array elements where the condition inside is true. @ refers to the current element being tested.

{
  "users": [
    { "id": 1, "name": "Ada",   "active": true,  "role": "admin" },
    { "id": 2, "name": "Grace", "active": false, "role": "engineer" },
    { "id": 3, "name": "Alan",  "active": true,  "role": "engineer" }
  ]
}

matched 2 nodes

$.users[0].name → "Ada"
$.users[2].name → "Alan"

• Extracting fields from an API response. A response body nested four or five levels deep — pagination wrapper, data envelope, array of records — turns into one expression like $.data.items[*].id instead of a defensive chain of null checks.
• Querying a large config or infrastructure file. Recursive descent is the useful one here: $..region finds every region key in a deeply nested Terraform-style JSON export, regardless of how many layers of nesting separate one occurrence from another.
• Filtering an array of records by a condition. A JSONPath filter such as $.orders[?(@.status=="failed")]answers “which of these” directly, which is the most common reason people go looking for a JSONPath filter in the first place — they don't want the whole array, they want the subset that matches one condition.

The one thing worth being exact about: JSONPath does not have a single, universally implemented specification the way JSON itself does. The original 2007 proposal described the core syntax, but filter expressions, negative array indices, and multiple-key selection were never pinned down precisely, so different libraries diverge on edge cases — one implementation accepts [?(@.price < 10)] with spaces around the operator, another doesn't; some support [-1]for the last array element, others don't; quoting rules inside filter strings vary too. RFC 9535, published in 2024, standardizes a lot of this, but plenty of tools you'll run into still predate it or intentionally diverge from it. The practical consequence: don't trust a JSONPath expression by reading it — test JSONPath expressions against the actual document and look at what actually matched. A gotcha worth internalizing is that a filter expression can silently match zero nodes on a typo (a misspelled field name, a stray space, a comparison against the wrong type) rather than throwing an error, so “it parsed” is not the same guarantee as “it matched what I meant.”

expression: $.users[?(@.Active==true)]
             (note the capital "A" — the field is "active")

matched 0 nodes

A JSONPath tester makes that check trivial by showing every matching node alongside its normalized path, so you can see at a glance whether an expression matched three nodes or zero, and exactly which ones, before that expression ships inside application code. GenKitLab's JSONPath Tester runs an expression against a document and lists every matching node with its normalized path — filters, wildcards, and recursive descent all included — entirely client-side, so nothing you paste is uploaded anywhere. If the document itself needs cleaning up first, JSON Formatter handles validating and pretty-printing it before you start querying.