JSON Array Filter Tool
Filter arrays of JSON values by a literal or dot-path field using type-aware text, number, boolean, null, JSON, regex, existence and range conditions without mutating original records.
A literal key matching the full text wins before dot traversal. Array indexes such as items.0.id are supported.
Matched counts, missing-path information, diagnostics and filtered JSON output will appear here.
Filtering Is Easier to Trust When Missing Is Not Quietly Turned Into null
These records are different: one has { "status": null }, another has { "status": "" }, and a third has no status member at all. Converting all three to one falsy value hides useful information.
The path resolver tracks whether a property actually exists, which lets Exists/Missing filters and diagnostics distinguish absence from an explicitly present value.
user.role Is a Convenience Path, Not JSONPath
The field path syntax is intentionally small. user.role walks object properties and items.0.id can walk an array index. It does not implement JSONPath filters, recursive descent or JSON Pointer escaping.
If an object literally has a key named user.role, that direct key wins before nested traversal. The sample includes that case so the rule is visible rather than hidden.
Numeric Comparisons Do Not Auto-Coerce "10" Into 10
A JSON string "10" and JSON number 10 are different values. Automatic numeric coercion can make messy exports appear cleaner than they are and can silently accept malformed records.
Greater/less/between conditions therefore require an actual finite JSON number in the record. If the API returns numbers as strings, that is useful information to fix or normalize deliberately.
String Operations Stay String Operations
Contains, starts-with, ends-with and regex are only applied to JSON string fields. An object is not quietly converted to [object Object], and the number 123 is not treated like the text "123".
Case-insensitivity and trimming are optional because both can change data semantics. A customer code with a leading space may be bad data, not something a filter should hide.
Diagnostic Metadata Must Not Overwrite User Fields
A common shortcut is to annotate matching objects with fields such as_index, _match or _reason. If a source record already uses one of those names, diagnostic output can overwrite real application data.
Diagnostic metadata stays outside the original records. In diagnostic mode, each source record is wrapped in a separate object containing sourceIndex, matched, reason, and actualValue.
Duplicate JSON Keys Are Already Lost by the Time Normal Filtering Starts
{
"role": "editor",
"role": "admin"
}JavaScript JSON parsing keeps the later member. A filter cannot recover the earlier value from the parsed object. The source text is checked for duplicate member names before filtering so a successful match is not mistaken for evidence that the original JSON was unambiguous.
A Regular Expression Can Be Valid and Still Be Expensive
JavaScript regular expressions run on the browser's main thread. A pattern with heavy backtracking can take a long time on certain input even when the pattern is syntactically valid. There is no regex timeout or sandbox around a pasted pattern.
For untrusted patterns or very large datasets, move the filter into a controlled script or service where execution time and input size can be limited.
Browser Filtering Is Best for Review-Sized Data
Pasted arrays are useful for API samples, fixtures, exported records, debugging and one-off investigation. Large production datasets are usually better handled with jq, a local script, database query or application-level pipeline where memory use and filter logic can be versioned and reproduced.
The 100-row output limit can keep a browser result manageable while still evaluating full counts. It is an output convenience, not pagination or streaming processing.