The error position is the point
Every JSON tool can tell you a document is invalid. What you actually need is where, and browsers are unhelpful here: the message from JSON.parse differs between Chrome, Safari and Firefox, and whether it includes a position at all has changed between V8 versions. So this tool parses twice. The browser's own parser decides validity, and if it rejects the document a second hand-written scanner re-reads the input to report the precise line and column, with the offending line shown and a caret under the character.
That second pass runs only when something is wrong, so a valid document costs nothing extra. And the messages name the actual mistake rather than the symptom: a trailing comma, a single-quoted string, a comment, an unescaped newline inside a string, and a leading zero on a number are each reported as themselves, because those five account for most hand-edited JSON failures.
Duplicate keys, which no parser warns you about
If an object contains the same key twice, JSON is technically valid and every parser silently keeps the last one. The field you meant is simply gone, with no error anywhere. Every real instance of this is a bug, usually from a merge or a hand edit, so this tool flags it as a warning with the line number even though the document parses cleanly.
Querying with a JSON Pointer
The path box takes an RFC 6901 JSON Pointer - the same syntax that JSON Schema validation errors, JSON Patch and OpenAPI already use. That means a pointer copied straight out of a validation failure resolves here unchanged, which is the common case for using it at all. A dotted path would have read more naturally and cannot express a key containing a dot, which real documents contain.
- Format or minify, with two-space, four-space or tab indentation
- Optional alphabetical key sorting, for diffing two API responses
- Depth, key count, object and array counts, and the size saved by minifying
- Up to 2 MB, refused rather than silently truncated beyond that
What it will not do
It does not accept JSON5, JSONC or any other relaxed dialect: comments, trailing commas and unquoted keys are reported as errors, because accepting input that your own parser will reject would make this tool useless as a check. It also does not validate against a JSON Schema - that is a different job with a different output.
One limitation worth knowing because it is invisible: numbers are re-serialised by the browser's JSON implementation, so an integer beyond the precision of a 64-bit float, such as a nineteen-digit id, comes back rounded. That is JavaScript rather than this tool, and the fix in your own code is to carry such values as strings.