Why another JSON formatter?
Because the JSON you debug at work is frequently sensitive: API responses containing tokens, Terraform state fragments, webhook payloads with customer data, and most online formatters are backend services that see everything you paste. This one is a single JSON.parse/JSON.stringify round-trip in your browser. It also does the one thing that matters most when JSON is broken: it converts the parser's opaque "position 847" into a line, a column, and a caret pointing at the offending character.
The errors you'll actually hit
Ninety percent of invalid JSON in operations comes from five habits: trailing commas (legal in JavaScript, fatal in JSON), single quotes (JSON requires double), unquoted keys, comments (JSON has none; that's why many tools moved to YAML or JSON5 for configs), and literal newlines inside strings (must be \n). If a config "worked yesterday", diff it and look for exactly these.
Format for humans, minify for machines
Two-space indentation is the ecosystem default (npm, most linters); four spaces reads better for deeply nested cloud API responses. Minifying strips insignificant whitespace only (the data is untouched) and matters when a payload must fit a size limit (some webhook receivers and message queues cap at 256 KB) or when you're embedding JSON inside another config format and want it on one line.
Validation vs. schema validation
This tool answers "is it syntactically JSON?", which catches the copy-paste breakage that causes most incidents. It deliberately does not answer "is it the right JSON?"; that's a job for JSON Schema and tools like ajv or your API's own validation, run in CI where broken configs get caught before deployment rather than after.