JSON Path Finder

Every line describes one leaf value: the full path, an equals sign, then the value. Object keys join with dots (order.customer.name) and array elements append a zero-based index in brackets (order.items[1].sku). The list is depth-first in document order, so it reads top to bottom in the same sequence as the JSON itself — every path under items[0] appears before the first path under items[1], which makes it easy to eyeball one record at a time.

The $ root marker appears when there is no object key to start a path from. A top-level array lists $[0].sku and $[1].sku; a document that is a single bare string or number collapses to one line, $ = value; a document that is just {} or [] prints $ = {} or $ = []. When the top level is a non-empty object, paths start directly at the first key — order.id, not $.order.id — because that is exactly what you will type after a variable name in code.

Two details keep the list honest. Empty containers are not silently dropped: an empty object prints as path = {} and an empty array as path = [], so a key that exists-but-is-empty never masquerades as missing. And values are rendered in their JSON form — strings keep their double quotes, so "2" and 2 stay distinguishable at a glance — but anything longer than about 60 characters is cut with an ellipsis so a giant embedded blob cannot break the one-line-per-path layout.

In JavaScript the copied path works verbatim after your variable name: obj.order.items[0].sku. If any branch might be absent, switch to optional chaining — obj.order?.items?.[0]?.sku — which yields undefined instead of throwing. Utility libraries take the path as a string: Lodash's _.get(obj, "order.items[0].sku") accepts the exact path this tool prints, which makes the list a copy-paste source for config lookups and defensive reads alike.

Python has no dot access on dicts, so each segment becomes its own subscript: data["order"]["items"][0]["sku"] — quote the keys, leave the array index bare. A missing key raises KeyError, so for optional branches chain .get() calls (data.get("order", {}).get("id")) or reach for a path library like glom, which accepts the dotted string "order.items.0.sku" directly.

For jq on the command line, prefix the path with a dot: jq '.order.items[0].sku' response.json. Keys that are not plain identifiers need quotes inside the expression, as in ."content-type". Notice what stays constant across all three: the segment names and index positions never change, only the punctuation around them. That is why one canonical dot-and-bracket list is enough to feed every runtime you work in.

JSONPath is a query language. An expression like $.store.book[?(@.price < 10)].title describes values by their properties, and an engine returns whichever ones match — with wildcards ($.items[*].sku), recursive descent ($..price), and filter predicates along the way. It is the right tool when you already know the document's shape and want to select from it programmatically.

A path finder inverts that. There is no query to write: it enumerates every concrete path that exists in this specific document, with the value sitting at each one. That is the operation you actually need when staring at an unfamiliar payload, because you cannot write a correct selector for a structure you have not seen yet. Enumeration answers the prior question — what is here, and what is it called.

The two compose naturally. Find the concrete path in the list, then generalize it into a query by prefixing $. and widening the parts that should vary: order.items[0].sku becomes $.order.items[*].sku to select every SKU, or $.order.items[?(@.qty > 1)].sku to filter. The enumerated list is the ground truth; the JSONPath expression is the abstraction you build on top of it.

The output is plain text, so bring text tools to it. Ctrl+F for a value you already know — "ord_9412" — and the line it sits on hands you the path: reverse lookup, the one thing collapsible tree UIs make tedious. Searching for a key fragment like .sku = shows every location where that field occurs, which immediately reveals whether it always lives at the same depth and always holds the same type.

The list doubles as a structural profile. The status line reports the total path count, and the highest index printed under items[ tells you the array's length without scrolling — the last element is items[7], so there are eight. Because only paths that actually exist are printed, comparing the lines under items[0] against items[7] exposes records with missing fields — an absent line is an absent key, which is precisely the kind of inconsistency that breaks mappers and deserializers in production.

When the job shifts from looking up one path to understanding the whole shape, lines stop being the best medium. The button above the output carries the same JSON into the full editor, where you can walk it as a collapsible tree or a mind map, format and validate it, and ask the AI copilot to explain unfamiliar fields — AI actions use credits, and new accounts start with 1,000.