JSONPath Tester

A deliberately bounded subset: $ for the root; .key or ['key'] for child access; [n] for a non-negative array index; [*] for a wildcard over every array element or object value; ..key for recursive descent (find that key at any depth); [start:end] for an array slice with ordinary JS-slice semantics (end exclusive, start/end optional, negative offsets allowed); and [?(...)] filters comparing @.field to a JSON literal or another @.field using == != < > <= >=, or a bare @.field as a truthy/existence check. Segments chain left to right, e.g. $.store.book[?(@.price<10)].title.

Multi-key unions like $.a['x','y'], function calls such as length() or count(), and any script/filter expression beyond the single comparison form described above are all unsupported and will either fail to parse or simply not match. Negative indices are also unsupported for the plain [n] index form specifically (only for slices) - use a slice like [-1:] instead of [-1] if you need the last element.

A field that is absent entirely resolves to 'undefined', not JSON null, so a comparison against it (other than !=) is treated as false rather than matching. @.isbn==null will only match an item that explicitly has "isbn": null, not one that omits the isbn key altogether - this mirrors how the underlying JS property lookup behaves and is a deliberate simplification rather than full JSONPath-spec null coercion.

Yes - evaluation stops and throws a clear error after visiting 5000 nodes, so a huge document combined with a very broad wildcard or recursive-descent expression (e.g. ..key over tens of thousands of nested objects) will hit that cap instead of freezing the tab. Ordinary bookstore-sized JSON documents are far below this limit.