JSONPath Tester
Try JSONPath expressions against a sample API response before adding a selector to your code or automation.
- Start with a simple path such as $.users[*].name.
- Inspect each matched path and value in the output.
- Keep a formatted copy of the JSON nearby while developing a query.
This tool runs entirely in your browser. Your JSON is not uploaded, stored, or logged.
Prototype selectors against real payloads
JSONPath is useful when you need a few fields from a deep response without writing a one-off traversal. Test the expression against a real sample here, confirm the matches, then move the path into your script or automation.
Start narrow (`$.items[0].id`), then widen with wildcards or filters once the shape is clear. Format the document first so you can see which nodes you are targeting.
Filters, wildcards, and what they hide
The wildcard is the part people overuse: a path like $.items[*].id returns every id in the array with nothing to say about which item each one came from. That is fine when all you want is the list of values, and a liability ten minutes later when you are working out why eight results came back from a two-item collection.
Filters read naturally and behave differently across implementations. JSONPath is a proposal with several dialects, so a path that resolves here may need adjusting in Python, Java, or a hosted proxy. Test the expression against a real sample, then test the same path in the library you will actually ship.
Practical uses beyond debugging
A working JSONPath is a small, reviewable selector you can reuse:
- Pulling one field out of a webhook payload in an automation step.
- Spot-checking an API contract after a deploy, by asserting the path still resolves.
- Feeding a nested value into a monitoring check without writing a parser.
- And keep it short: if a selector needs several brackets and a filter to be correct, plain code is usually easier to read six months later than the expression that replaced it.
The operators worth knowing
Four forms cover most real use: a direct child path ($.user.name), a wildcard over an array or object ($.items[*].id), recursive descent ($..price, which searches at every depth), and a filter ($.items[?(@.price > 10)]). Recursive descent is powerful and easy to overuse — it finds a field wherever it appears, including in places you forgot were in the document.
Filters are where implementations disagree most: whether @ is required, whether a comparison coerces types, and which functions exist. Test the exact expression against the exact library you will ship, rather than assuming the dialect here matches your runtime.
JSONPath, jq, and plain code
JSONPath is the right tool for a short selector that pulls a few values from a known response. For anything with a loop, a computed value, or a transformation, jq on the command line or a few lines of code will be clearer and testable.
A useful rule: if the selector fits on one line and does one thing, keep it. If you are nesting filters and unions to express logic, the logic belongs in code where it can be named and unit-tested.
Frequently asked questions
What is a good first JSONPath to try?
Start with $. followed by a top-level key you can see in the formatted document, then drill down. For arrays, try $.items[*].name once you know the collection name.
Is my JSON uploaded for JSONPath queries?
No. Queries run in your browser against the document you pasted.
What is recursive descent in JSONPath?
$..name finds every name field at any depth, not just the top level. It is shorthand for “search everywhere” — convenient against an unknown shape, risky once the document has several name fields.