TXT · Text & Data tools

JSON Query Playground

Input JSON
Result
JSONPathengine0matches0input bytes0 mseval time

Test a query against real data

Debugging a JSON query inside a pipeline is slow: edit the expression, rerun the job, read the logs. Here the loop is immediate. Paste the document once, then edit the query and watch the result change on each keystroke. The match count in the stats row tells you at a glance whether a filter caught what you expected.

The Example button loads the classic bookstore document with a filter query in the syntax of the current engine, which doubles as a syntax reminder.

JSONPath, JMESPath, and jq

The three languages solve the same problem with different syntax and different rules. The same job, “titles of books under 10”, looks like this in each:

  • JSONPath: $.store.book[?(@.price < 10)].title
  • JMESPath: store.book[?price < `10`].title
  • jq: .store.book[] | select(.price < 10) | .title

Differences that regularly cause confusion:

  • JSONPath starts at $, uses @ for the current node inside filters, and always returns an array of matches. A query that matches nothing returns [], not an error.
  • JMESPath requires backticks around literals in filters (`10`, not 10). Unquoted numbers in comparisons are the most common JMESPath syntax error.
  • jq is a pipeline language: each | feeds the previous result into the next filter. It is the most expressive of the three, with functions like map, group_by, and to_entries, and it can build entirely new structures, not only select from existing ones.

Switching engines

The engine switch keeps the document and the query text, which is the fastest way to translate an expression from one language to another: get it working in the language you know, switch tabs, and adjust until the result matches. Expect syntax errors immediately after switching, since the languages are not compatible.

Errors

Two kinds of errors show up in different places. A JSON parse error appears under the input pane and blocks all querying, with the parser’s position information. A query error appears under the result pane and names what the engine rejected, such as an unexpected token in a JSONPath filter or an unknown jq function.

Result shapes

The result pane prints the query output as formatted JSON. Note the special cases: JMESPath returns null for a path that does not exist rather than erroring, jq’s .foo on a missing key also yields null, and JSONPath simply returns fewer matches. If a query “works” but returns null, the path is usually valid syntax pointing at a key that is not there, and a typo check beats a syntax check.

Frequently Asked Questions

Paste a JSON document, type a query, and the matching values appear as you type. Three query languages are supported: JSONPath, JMESPath, and jq. The query and selected engine are stored in the URL, so a link reproduces the exact test.

Use the one your target system uses. JSONPath appears in tools like Kubernetes kubectl and many API gateways, JMESPath is the query language of the AWS CLI and Ansible, and jq is the standard command-line JSON processor.

JSONPath collects every node the path matches, so results always arrive as an array of matches. JMESPath and jq evaluate an expression, so the result has whatever shape the expression produces: a value, an object, an array, or null.

jq is the real jq program compiled to run in the page, and it is several megabytes. It loads the first time you switch to the jq tab; after that, queries run at the same speed as the other engines.

No. Only the query text and the chosen engine go into the URL. The JSON document stays in the page and is gone when you close the tab.

Explore Our Tools

Browse all tools