JSON (JavaScript Object Notation) is the default format for moving data between servers, APIs, and applications. It's built from just two structures — objects (key-value pairs) and arrays (ordered lists) — which is exactly why it's so widely supported and also why small syntax mistakes break it completely.
Why raw JSON is unreadable
Most JSON you'll actually encounter — an API response, a config file, a log entry — arrives as one unbroken line of text. Whitespace adds bytes without adding meaning for a machine, so it gets stripped before transmission. That's efficient to send and impossible to read, which is the entire reason a formatter exists: it reintroduces indentation and line breaks so a human can follow the structure, without touching the underlying data.
The errors that account for most "invalid JSON" messages
- Trailing commas — a comma left after the last item in an array or object, like [1, 2, 3,]. Valid in a JavaScript object literal, invalid in strict JSON.
- Single quotes — JSON requires double quotes for both keys and string values. {'key': 'value'} fails; it must be {"key": "value"}.
- Unquoted keys — JavaScript allows {key: "value"}, but JSON requires every key to be a quoted string.
- Missing or extra commas — a comma missing between two properties, or an extra one before a closing brace, is the single most common copy-paste error.
- Unescaped characters — a raw newline, tab, or backslash inside a string value breaks parsing; these need to be escaped as \n, \t, \\.
- JavaScript-only values — undefined, NaN, and functions are valid in JavaScript but have no JSON equivalent; they need to become null or a string.
Reading the error message
When a parser rejects JSON, the error usually names a position — something like "Unexpected token , in JSON at position 42". That position is a character offset into the string, not a line number. The fastest way to use it: paste the JSON into a formatter first, so the structure is visible, then count characters (or use a formatter that highlights the exact failing line) from the start.
Formatting vs. minifying
These are opposite operations on the same data. Formatting adds indentation so a human can read the structure. Minifying strips that whitespace back out to produce the smallest possible payload for a network request. Use formatted JSON while debugging or documenting an API, and minified JSON for the actual production payload.
Best practices
- Validate JSON before it ships to a production API — malformed payloads fail silently in a lot of client libraries.
- Keep nesting shallow where you can; JSON more than 4-5 levels deep is hard for the next person (including future you) to follow.
- Never paste real API keys or customer data into a third-party formatter, including this one — treat online tools as public by default.