JSON's grammar is small and unforgiving: object keys must be double-quoted strings, trailing commas are illegal, and there's no comment syntax at all — three restrictions that account for a large share of 'invalid JSON' errors people hit when hand-editing a config file that started life as JavaScript, which does allow all three. A validator that points at the exact line and character of the failure saves the trial-and-error of deleting things until it parses.
JSONL (JSON Lines) is a different but related format: one complete, independent JSON value per line, common in log files and streaming data pipelines because it lets you process records one at a time without holding the whole file in memory. It is not a JSON array with the brackets removed — a single malformed line fails independently without invalidating the rest of the file, which is precisely its appeal for append-only logs.
Because JSON is the transport format for so much of the web, its string values are also where a lot of other interesting data ends up hiding — an access token in a token field, an AWS key accidentally logged in a debug field, an email address in a field that shouldn't have PII at all. Formatting the structure is necessary but not sufficient scrutiny for a blob of JSON you're about to log, store, or paste somewhere.
This tool detects JSON versus JSONL automatically, pretty-prints with consistent indentation, and reports the exact position of a syntax error when parsing fails. On valid input, every string value is also passed through the other matchers — so a JWT sitting in a token field or a credential sitting in a config value gets flagged as part of the same pass, not as a separate manual step.
Edge cases worth knowing
- A trailing comma left over from reordering keys
- {"a":1,"b":2,} is invalid JSON — the trailing comma after the last property is a common holdover from JavaScript object literals or from deleting the last key without deleting its preceding comma. The formatter's error message points at the exact comma.
- JSONL where one line is valid JSON but the file as a whole isn't
- A log file that's actually a JSON array missing its enclosing brackets and comma-separated instead of newline-separated will fail JSONL parsing on most lines. This tool reports which specific lines failed rather than a single failure for the whole file.
- A deeply nested object that's technically valid but hard to eyeball
- There's no structural limit on nesting depth in JSON. Extremely deep nesting is pretty-printed with full indentation, but for genuinely enormous structures, collapsing sections in the output view is more useful than a wall of open braces.
Common mistakes
- Adding a trailing comma or a JavaScript-style comment to a .json config file and getting a parse error with no obvious cause.
- Treating JSONL as a JSON array by wrapping it in brackets and joining lines with commas instead of parsing each line independently.
- Logging a full request or response object without checking whether any field happens to contain a token, key, or PII.
- Assuming JSON preserves key order or number precision identically across every parser — very large integers can lose precision when round-tripped through JavaScript's JSON.parse.