Why the error location matters more than the error message#
"Unexpected token in JSON" tells you something is wrong. It does not tell you where, and a config file, an API response, or a build artifact pasted in for debugging is often hundreds of lines long. This tool surfaces the exact line and column JavaScript's own parser reports the failure at, which turns a search through the whole document into a jump straight to the problem — usually a trailing comma, a missing quote, or a stray comment (JSON has no comment syntax, despite how often people try to add one).
Format versus minify versus validate#
Formatting adds consistent indentation for human readability — useful when debugging a compressed API response or reviewing a diff. Minifying does the opposite: it strips every character that does not change the meaning, which matters when JSON ships inside a URL parameter, an environment variable, or anywhere every byte counts. Validate-only exists for the case where you just need a yes-or-no answer without generating any output to copy.
What "valid JSON" actually requires#
JSON is stricter than it looks. Object keys must be double-quoted — single quotes and unquoted keys are invalid, even though both are common in JavaScript object literals. Trailing commas after the last item in an array or object are not allowed, unlike in JavaScript. Comments are not part of the spec at all. All three are the most common reasons a document that "looks like JSON" fails to parse, and all three are things this tool catches and locates precisely.