Positioning of this Tool
This tool is a lightweight evaluation tester designed to inspect and extract values from structured JSON data without requiring a full RFC 9535 engine or a WebAssembly port of jq.
Internally, traversal operates in JavaScript via a direct traversal algorithm that inspects nodes top-down, checking own object properties rather than inherited prototype members.
It does not construct an exhaustive Abstract Syntax Tree (AST), execute jq filter expressions, or process dynamic transformations, making it practical for developers who want to inspect API payloads quickly.
The engine recognizes root identity via an empty string, ., or $. Queries operate synchronously without background Web Workers, bounded by concrete input limits: JSON text up to 1,000,000 UTF-16 code units, query strings up to 2,000 UTF-16 code units, a maximum query depth of 128 path segments, a JSON nesting depth of 128 levels, and up to 100,000 parsed value nodes.
Traversal evaluates up to 200,000 node visits and collects up to 20,000 matched items per step, with formatted output bounded at 2,000,000 UTF-16 code units checked prior to serialization.
Input parsing adheres to standard JSON grammar where numbers like 1e309 are syntactically valid JSON, but because JSON.parse evaluates them to Infinity, an explicit finite number check subsequently rejects the payload; literal Infinity and NaN tokens remain invalid JSON grammar and are rejected outright.
The evaluator serves as an in-browser inspector for quick schema exploration and path verification rather than replacing stream processors or offline command-line utilities.
When the JSON input is completely empty, the tool leaves the display blank, whereas an empty query string targets the root and returns the entire parsed JSON document.
Invalid JSON or malformed query expressions immediately surface clear diagnostic errors without generating partial or corrupted output.
When an existing path legitimately targets an explicit null, false, 0, or an empty string, the resulting value is preserved and can be copied seamlessly, whereas an unresolvable or missing path produces a dedicated non-matching indicator rather than a misleading JSON null literal.
Client-side evaluation executes synchronously on the main UI thread without Web Workers, operating within defined memory and code-unit boundaries to facilitate straightforward client-side payload inspection.
Keys and Subscripts
Navigating JSON structures begins with selecting specific object properties and array subscripts. In this tool, paths can start with either the standard JSONPath root token $ or the jq-style root token ..
An empty query string, a solitary $, or a single . evaluates directly to the root element itself. From there, dot notation allows child access using standard identifiers like $.store.book or .store.book.
In addition to standard ASCII identifiers, dot notation accommodates non-ASCII characters, whereas keys containing whitespace, dots, brackets, quotes, or unusual punctuation must be enclosed within quoted bracket expressions.
The evaluator inspects own object properties only, preventing prototype property leakage. Bracket notation supports both single and double-quoted keys—such as $.store['book'] or $.store["book"]—and properly decodes escape sequences, Unicode code points, and literal dots or closing square brackets ] placed within the quoted string.
Direct array element retrieval is fully supported using non-negative zero-based integers enclosed in brackets, such as .store.book[0].title or $[0].
Because the path reader parses balanced bracket structures without stripping closure characters, indices are matched cleanly against targeted arrays.
However, negative indexing—such as [-1] to read from the end of an array—is not supported, and attempting to supply negative integers or invalid index syntax results in an explicit syntax error rather than silent mismatch handling.
When a path expression targets a singular node, the tool outputs that exact matched value directly, preserving its primitive or composite representation.
Wildcards and Slices
When inspecting repeating collections or listing all properties across an object, wildcard expressions and bounded array slicing provide flexible multi-node extraction.
The engine supports both dot wildcards (.*) and bracket wildcards ([*]). When a wildcard is encountered, the evaluator iterates across all elements if the current target is an array, or across all own enumerable property values if the target is an object, subsequently continuing the remainder of the query against each matched child node.
For arrays, multi-node paths return an array containing each matching element without flattening or collapsing any selected inner array structures, thereby preserving the original dimensional boundaries of nested collections.
To extract a contiguous subset of an array, the tool supports non-negative slice expressions formatted as [start:end] as well as open-ended variations [:end], [start:], and [:].
The slice evaluates with a zero-origin non-negative start index and a non-negative end index where the end boundary is exclusive, in accordance with conventional slicing semantics.
When omitted, the start index defaults to 0 and the end index defaults to the length of the target array, allowing expressions like [:2] to select up to the first two elements and [1:] to select all elements after index 0.
Step increments (such as [0:10:2]) and negative slice boundaries are not supported and trigger syntax errors. The maximum output threshold of 2,000,000 UTF-16 code units is evaluated before full serialization to constrain buffer allocation during multi-node collection.
Recursive Search
For deeply nested data architectures where the exact level of a target key is unknown or varies across objects, the recursive descent operator (..) enables exhaustive search traversal.
The tool fully supports recursive descent from both intermediate paths (such as $.store..price) and directly from the root element (such as $..name or ..name).
When a recursive descent segment is encountered, the engine executes an iterative preorder traversal across the entire subtree, inspecting all nested objects and arrays without risking call-stack overflow on deep structures.
Recursive traversal checks object keys against own properties and collects matching values into a consolidated result list.
Unlike engines that collapse array elements into an unstructured single list, recursive queries that return multiple matches package the discovered items into a standard array containing each matched value without stripping or flattening any internal arrays found at those paths.
If a path resolves to multiple nodes, the output is represented as an array of all collected values. To ensure bounded performance across massive object graphs, traversal halts and reports an error if the total number of visited nodes exceeds 200,000 or if the number of collected matches exceeds 20,000 at any individual step.
Contextual structure within individual matched nodes is fully preserved, ensuring that compound objects and lists retain their nested integrity upon output.
Differences from JSONPath and jq
While this tool shares intuitive syntax similarities with RFC 9535 (JSONPath) and the jq command-line utility, it is deliberately scoped as a path-based value extractor and does not implement the full syntax of either standard.
A fundamental distinction is the complete absence of conditional filter expressions ([?(@.price < 10)]), jq filter pipelines (| select(...)), mathematical operators, string interpolations, or built-in functions such as length or keys.
Any attempt to supply filter expressions, union lists (['a', 'b']), step slices, or jq piping constructs will be detected as invalid syntax and rejected with an explicit error message, even if earlier segments of the query path do not match an existing node in the JSON input.
Furthermore, result representation is strictly deterministic. Single-target queries yield the exact value found at that path, while wildcard, recursive, or slice queries yield an array containing each matched value.
If a query path cannot be found within the data, the tool displays a distinct "No match found" status rather than producing an ambiguous JSON null literal.
This allows clear differentiation between non-existent nodes and real JSON values like null, false, 0, or "", all of which can be inspected and copied via the dedicated clipboard action.
Numbers follow standard JavaScript IEEE-754 precision, and non-finite numeric literals (Infinity, -Infinity, NaN) in raw JSON input are flagged as syntax violations rather than converted to null.
API Response Investigation Procedures
Using this tool effectively during API response inspection and debugging streamlines payload analysis from RESTful endpoints or GraphQL responses.
Begin by pasting the raw JSON payload into the input text area. The parser will immediately validate the payload syntax according to standard JSON parsing rules, rejecting unquoted keys, trailing commas, and non-finite numbers.
If the input is valid, type the query path into the path input bar. You can inspect root collections using direct dot notation, such as $.data.users, or target root elements directly with $ or ..
If you wish to isolate a specific record, provide a bracketed non-negative integer index such as $.data.users[0].
To extract specific attributes across entire collections, use the bracket or dot wildcard syntax, such as $.data.users[*].email or $.data.users.*.id.
For complex, variable structures where target fields appear across arbitrary depths, invoke recursive descent via $..email. If an element does not exist, the interface displays a dedicated non-matching indicator; if the node evaluates to null, false, 0, or an empty string, that literal value is rendered and made available for clipboard copy.
The formatted preview updates synchronously in the extraction viewer, giving you rapid, dependable feedback on path validity before embedding query expressions into integration test suites or production codebases.
When working with complex response payloads, refine your workflow for boundary cases. When a property key contains a dot or closing bracket, enclose it in quotes within brackets, such as $['user.name'] or $['field]val'].
Before copying an extracted fixture, check the inspector status to distinguish a missing property from an explicit null value. Because this browser tool provides an operational subset rather than full jq or RFC9535 compliance, always verify your query expressions against the destination engine before committing them to production scripts.