Free JSON Path Extractor

How It Works

1. Paste your JSON: Enter any JSON object or array in the input field.
2. Enter a JSONPath expression: Type a path like $.store.book[*].author or $..name to select the data you need.
3. View extracted results: Matching values appear in the output panel instantly. Copy the result or export it.

Why Use JSONPath Extractor?

When working with complex API responses or deeply nested JSON, extracting specific values by hand is slow and error-prone. JSONPath is the query language for JSON, similar to XPath for XML. It lets you pinpoint exactly the data you need using a concise path expression, whether that is a single nested value, all items in an array, or filtered records matching a condition. This tool makes JSONPath exploration interactive without writing code.

Features

• JSONPath essentials: Dot notation, bracket notation, wildcards (*), recursive descent (..), array indices and the .length property. Filter expressions like [?()] are not currently supported.
• Live evaluation: Results update as you type your JSONPath expression.
• Formatted output: Extracted values are displayed as pretty-printed JSON.
• Multiple matches: Returns all matching nodes from the JSON document.
• Error reporting: Clear messages when the path expression is invalid or produces no matches.

Frequently Asked Questions

What is JSONPath?

JSONPath is a query language for JSON documents, analogous to XPath for XML. A path like $.users[*].name selects the name field from every object in the users array. It is widely used for API testing, data transformation, and JSON processing.

How do I filter array items by a condition?

Use a filter expression: $.items[?(@.price < 50)] returns all items where price is below 50. The @ symbol refers to the current element being evaluated.

Does it support recursive search?

Yes. The .. operator searches recursively through all levels. For example, $..name finds all name keys anywhere in the JSON structure, regardless of nesting depth.

From a blog post to RFC 9535: the 17-year road to a JSONPath standard

Stefan Gössner proposed JSONPath in a single blog post in February 2007, adapting the XPath idea to JSON. He published a reference JavaScript implementation, sketched the syntax (the $ root, dot and bracket child operators, .. for recursive descent, * for wildcard, [start:end:step] array slicing, [?(...)] filter expressions) and the wider ecosystem ran with it. Implementations proliferated: jsonpath for JavaScript, JsonPath for Java, jq (Stephen Dolan, 2012) which is JSONPath-adjacent but its own thing, jsonpath-ng for Python, JMESPath (AWS, 2014) as a stricter rival. The trouble: every implementation drifted. Filter syntax, recursion semantics, regex matching, root identifiers, all subtly different across libraries. A 2023 comparison study by Carsten Bormann et al. tested 41 distinct JSONPath implementations against the same input and got 41 different result sets for the same expression. The IETF JSONPath Working Group convened in 2020 to fix this. RFC 9535 «JSONPath: Query Expressions for JSON» was published in February 2024, becoming the first formal standard for JSONPath, 17 years after Gössner's original post. RFC 9535 codifies the syntax, defines a normalized output format, requires Unicode normalization for string comparisons, and adds a conformance test suite.

JSONPath syntax cheat sheet

The seven operators that cover most real-world queries:

• $ root. Every path starts here. $ by itself returns the whole document.
• .name child by name. $.store.book selects the book field inside store. Names with spaces or special chars need bracket notation: $['book title'].
• [0] array index. $.book[0] first element. $.book[-1] last element (RFC 9535 addition).
• [start:end:step] array slice. Python-style: $.book[1:3] elements 1 and 2, $.book[::2] every other element. step can be negative for reverse.
• * wildcard. $.book[*].title the title of every book. Also works as a property wildcard: $.store.* all immediate children of store.
• .. recursive descent. $..title finds every title field at any depth. Powerful but slow on big documents.
• [?(...)] filter expression. $.book[?(@.price < 10)] all books where price is below 10. @ means «the current element». RFC 9535 names this ? and standardises the comparison operators == != < <= > >= plus boolean && ||. This viewer's quick mode does not evaluate filter expressions, use a library like jsonpath-plus if you need them.

Where you actually reach for JSONPath

• kubectl output filtering. kubectl get pods -o jsonpath='{.items[*].metadata.name}' ships in Kubernetes and is a daily-used JSONPath consumer. The Kubernetes flavour drops the leading $ and has a few quirks worth noting if you live in that ecosystem.
• API testing with Postman or Insomnia. Test assertions like pm.expect(jsonData.items[0].status).to.eql('active') are usually expressed as JSONPath under the hood.
• Grafana / observability dashboards. JSON datasource panels query metrics using JSONPath; OpenTelemetry collectors use a JSONPath-like syntax to extract span attributes.
• Quick CLI extraction. Pair this tool with curl | jq for live API exploration: prototype the path in the viewer, then translate to jq syntax for shell scripts. (jq uses dot notation but is not strictly JSONPath.)
• ETL and data engineering. Airflow XCom mappings, dbt seed files, and SQL JSON column extraction all use JSONPath-like expressions to reach into nested payloads.
• Token inspection. Drill into a decoded JWT: $.payload.iss for the issuer, $..roles[*] for every role granted anywhere in the claim tree.
• Webhook handler design. Before writing the handler code, paste a real webhook payload and prototype the paths that pull out the fields your system cares about. Saves a round-trip with the upstream service.

Mistakes that bite

• Implementation drift. A path that works in one library can produce different results, or no results, in another. Before RFC 9535 nothing was standardised. Now look for «RFC 9535 conformant» in your library's docs (the IETF test suite is published with the RFC).
• Filter quoting. $.book[?(@.title=="Foo")] requires double quotes inside the filter in RFC 9535; many older libraries accept single quotes 'Foo' too. Mixing them is a common cause of «syntax error» in production.
• Recursive descent is greedy. $..* returns every value in the document, including nested objects and arrays themselves, not just leaves. On large documents this can take seconds. Narrow the path first, then descend.
• Integer-vs-string keys. JSON only has string keys, even when they look numeric. $.users.123 and $.users[123] mean different things in some libraries: the first looks for a property literally named "123", the second can be interpreted as array index 123.
• Negative slices. $.book[-1:] means «the last element» in RFC 9535 and most implementations, but pre-2024 some libraries treated negative indices as errors. If you target older parsers, use absolute indices.
• Forgetting $. A path without a leading $ is invalid in RFC 9535. Some implementations accept .store.book as shorthand, others reject it. Always prefix with $.
• Performance. Recursive descent .. on a 10 MB document can be O(n) per match. For data warehouse columns or hot loops, pre-extract once with $.., cache the result, then walk the cached array. Never run a complex JSONPath on every request.

JSONPath vs jq vs JMESPath vs JSON Pointer

• JSONPath (RFC 9535). Best for ad-hoc queries and configuration files. The syntax is familiar from XPath, the standard is fresh, multiple language libraries support it.
• jq. A full data transformation language, not just a path query. Adds map/filter/reduce, string functions, math, formatting. Better when you need to reshape data, not just extract it. Has its own syntax with dot notation but diverges from JSONPath at the filter level.
• JMESPath. A 2014 alternative used by AWS CLI (aws ec2 describe-instances --query "..."). Stricter and more functional than JSONPath, has a real grammar from day one, supports projections and pipe operators. Less common outside Amazon's ecosystem.
• JSON Pointer (RFC 6901). A 2013 standard for addressing a single value: /store/book/0/title. Cannot do wildcards, filters, or recursion. Used by JSON Patch (RFC 6902), JSON Schema $ref, and the Kubernetes patch API. Pick this when you need exact-address pointing, not querying.

More frequently asked questions

Is JSONPath the same as XPath?

Inspired by it, not identical. XPath was finalised by W3C in 1999 for XML, JSONPath was sketched by Gössner in 2007 to bring the same idea to JSON. The biggest differences: JSONPath uses . and [] instead of /, JSONPath has no concept of XML namespaces or attributes, JSONPath standardised much later (2024 vs 1999), so for years it was a de-facto syntax with many incompatible implementations.

Why does the same JSONPath give different results in different tools?

Because JSONPath wasn't standardised until RFC 9535 (February 2024). Before that, every implementation made its own choices about filter syntax, regex support, root identifiers, escaping rules, and edge cases (empty arrays, missing keys, type coercion in filters). A 2023 IETF working-group study tested 41 implementations on the same input and got 41 different result sets. RFC 9535 fixes this for new and updated libraries; older libraries will diverge until they migrate. Always check whether your library claims «RFC 9535 conformance».

Can I modify the JSON with JSONPath, or only read?

RFC 9535 defines JSONPath strictly as a query language: it returns values from a document, it does not mutate. To modify JSON, use JSON Patch (RFC 6902), which uses JSON Pointer paths and add/remove/replace/copy/move/test operations. Some libraries combine both (e.g. jsonpath-plus in JavaScript has an apply() mutation extension) but that is not standard JSONPath.

Does JSONPath support regular expressions in filters?

RFC 9535 added two regex functions: match(node, regex) matches the whole string, search(node, regex) matches any substring. Example: $.book[?(match(@.isbn, "^978-"))]. The regex flavour is I-Regexp (RFC 9485, a profile of XML Schema regex), not PCRE or JavaScript regex. Older libraries used their host language's regex flavour, which makes regex queries especially non-portable.

Is my JSON sent anywhere when I use this tool?

No. Path evaluation runs entirely in your browser's JavaScript engine. Open the Network tab in DevTools and run a query, you will see zero outbound requests during evaluation. Safe for API responses with secrets, database dumps with PII, or configuration files containing credentials.