Paste a JSON document, write a JSONPath expression, and see what it selects — with a live preview, the real matched values, and a genuine syntax error when the expression is wrong. Entirely in your browser.
JSONPath is the most widely known way to address parts of a JSON document, and Json Web Viewer evaluates it as a first-class query language inside the Transform modal — the same place JMESPath and real jq live. Pick JSONPath from the Language dropdown and the query field, the live preview, the copy affordances and the Apply button all behave exactly as they do for the other two. There is one result surface, not a separate JSONPath page with its own quirks.
Errors say what and where. A JSONPath tool that answers a malformed filter with
"invalid expression" has told you nothing. Write $[?(@.age >)] here and you get
Invalid JSONPath query: Expected expression after > at character 10 — the parser's own
message, with a position, passed through rather than flattened into a generic one. That is the same
line this app already holds for jq, whose errors are jq's own.
eval, and that is a deliberate engineering constraint
Many JSONPath implementations evaluate filter expressions like ?(@.price < 10) by
handing them to JavaScript's eval or the Function constructor. That is a real
source of past CVEs in this corner of the ecosystem, and it is also incompatible with a strict Content
Security Policy.
This site ships a CSP with no unsafe-eval, and adding JSONPath did not change it. Filter
and script expressions are parsed to a syntax tree and walked by an interpreter, so no string is ever
compiled into code. Property reads of constructor and __proto__ are refused
outright, and the browser's own CSP would block a compile even if one were somehow attempted. You can
read the policy on the security page.
Example — this JSON:
{
"store": {
"book": [
{ "title": "Dune", "author": "Herbert", "price": 9.99 },
{ "title": "Neuromancer", "author": "Gibson", "price": 12.50 },
{ "title": "Blindsight", "author": "Watts", "price": 4.00 }
],
"bicycle": { "color": "red", "price": 19.95 }
}
}with this JSONPath expression:
$..book[?(@.price < 10)].titlereturns:
[
"Dune",
"Blindsight"
]
Open the editor →
From there: paste your JSON, open Transform (the More ⋯ menu, or a middle-strip
button), switch Language to JSONPath, and type your expression. The
preview updates as you type, and nothing is applied to your document until you press Transform.
The common dialect: $ for the root, dot and bracket child access, wildcards
(*), array slices, recursive descent (..), filter expressions
(?(...)), script expressions, and the @property / @parent /
@root bindings. Expressions are evaluated by
jsonpath-plus, whose dialect
is a superset of Goessner's original proposal.
eval?
No. Filter and script expressions are parsed into a syntax tree and interpreted, never compiled with
eval or new Function. The site's Content Security Policy has no
unsafe-eval and was not relaxed to add this feature.
No. The expression and the document are both evaluated in your browser, in a Web Worker. There is no server to send them to — this is a static site.
No. The wizard generates JMESPath only — JSONPath expressions are typed by hand. If you select JSONPath as the language, the wizard says so rather than silently building something else.
Evaluation runs in a Web Worker, so a slow expression does not freeze the page and can be
cancelled outright. The document crosses into the worker as text, not a live object, specifically
so that nesting depth is not a transport limit — measured up to 100,000 levels deep with no issue,
and the same for every query language here, not a JSONPath-specific fix. JSONPath's own recursive
descent (..) is a separate matter: it walks one nesting level per call inside the
jsonpath-plus engine itself, so an expression that uses it can still hit a genuine stack limit —
reported as exactly that, not a hang. A more specific expression, or scoping the Path field to a
smaller subtree, works around it.
No. The JSONPath engine is a separate chunk (about 8 KB gzipped, 25 KB uncompressed) that only downloads the first time you actually run a JSONPath query. If you stick to JMESPath, or never open Transform at all, it is never fetched.
Usually, yes — JSON Path Finder emits a JSONPath for any node you click. One caveat: that output follows RFC 9535's escaping rules, and the evaluator does not process escape sequences inside quoted keys. So for the rare key containing a quote, a backslash, a square bracket or a control character, the copied path will not resolve here and needs adjusting by hand.
Prefer a different query language? See the jq playground, or JSON Path Finder to get a node's path by clicking it.