How to Format JSON (and Debug It When It Breaks)

Formatted (pretty-printed) JSON uses indentation and line breaks so humans can scan structure; minified JSON removes all optional whitespace so machines transfer fewer bytes. They carry identical data — only presentation differs.

Why JSON breaks

When JSON breaks, the culprit is almost always a trailing comma, a single-quoted string, an unescaped quote inside a string, or a comment pasted from documentation. JSON has no comments and no trailing commas; both are JavaScript object syntax, not JSON.

Another frequent issue is unescaped control characters or unescaped \ and " inside string values. A path like C:\Users\name must be written as "C:\\Users\\name" in JSON, or the backslash will eat the next character.

A reliable debug workflow

Paste the payload into the JSON Formatter to pretty-print and pinpoint errors. Validators report the line and column where parsing failed — look just before that position, not at the end of the file. Fix the syntax, re-validate, then minify only when you need compact output for an API.

For configuration files, keep a canonical formatted copy in version control and minify only at build or deploy time. Diffs of minified files are unreadable in code review; diffs of formatted JSON show exactly which keys changed.

Pretty-print vs minify: when to use which

Pretty-print for humans: logs, config, code review, debugging. Minify for machines: request bodies over the wire, embedded JSON in HTML, size-constrained storage. Neither changes types — a number stays a number, a string stays a string.

Arrays, nesting and null

Watch nested arrays and objects: an extra bracket at depth four is hard to spot by eye. Pretty-printing with consistent two-space indent makes nesting obvious. Remember that null, true and false are lowercase keywords in JSON — JavaScript's undefined and NaN are not valid JSON at all.

All three RovoTools JSON utilities parse locally in your browser, so API keys and private payloads in your JSON never travel anywhere.