Working with JSON text usually comes down to three different tasks: making it readable, making it compact, or checking that it's valid at all. These are three separate operations, even though they're often bundled into a single tool.
Formatting (pretty-print)
Formatting adds indentation, line breaks, and spacing around punctuation so the structure of the JSON is easy to read by eye. It's a purely cosmetic change — it doesn't affect the data, only how it's displayed.
Minifying
Minifying strips all unnecessary whitespace, line breaks, and indentation, leaving only the characters that are actually needed. This reduces file size, which matters when transmitting data over a network or storing large volumes of it — the underlying data structure itself doesn't change.
Validation
Validation checks whether the text is syntactically valid JSON. Common errors it catches: a trailing comma before a closing bracket, single quotes instead of double quotes, unquoted object keys, comments (which the JSON standard doesn't allow at all), or unclosed brackets. Valid JSON is a prerequisite for formatting or minifying to work in the first place.
When you need which
- Formatting — when debugging API responses or manually editing config files.
- Minifying — before sending data over the network or embedding it in production code.
- Validation — when diagnosing why a parser refuses to read a JSON file.
Why "safe" integers in JSON aren't as safe as they look
JSON numbers have no built-in size limit, but most JSON parsers decode them into a JavaScript number (or an equivalent double-precision float), which can only represent integers exactly up to 2^53 − 1 (9007199254740991). A formatter can pretty-print a field like "id": 9223372036854775807 without complaint, yet round-tripping that value through JSON.parse silently corrupts it. This is exactly why Twitter/X's API added a parallel id_str field back in 2011 — tweet IDs had grown past what a JSON number could hold losslessly, so large platforms now ship both a numeric ID and a string version of it side by side.
JSON5 and JSONC are not the same thing as JSON
Some environments (VS Code or TypeScript config files, for example) accept trailing commas, comments, and unquoted keys — that's the JSON5 or JSONC extension, not standard JSON (RFC 8259). A validator set to strict JSON will correctly reject such a file, even though an editor "understands" it just fine. If you need comment support, label the format explicitly as JSONC rather than assuming any JSON parser will accept it.