How to format JSON (and actually understand the errors)

JSON (JavaScript Object Notation) looks almost identical to a JavaScript object literal, which is exactly why it trips people up — it's stricter than what JavaScript itself allows.

The rules that actually matter

• Keys must be double-quoted strings. {name: "Ada"} is valid JavaScript but invalid JSON — it has to be {"name": "Ada"}.
• No trailing commas. ["a", "b",] fails. JavaScript arrays tolerate a trailing comma; JSON does not.
• No comments. Not //, not /* */. If you need comments, you're not writing JSON anymore (some tools use a JSON5/JSONC superset, but standard JSON parsers will reject them).
• Strings must be double-quoted, not single-quoted. 'hello' is invalid; "hello" is required.
• Numbers can't have leading zeros or a leading plus. 007 and +5 are both invalid; 7 and 5 are fine.

Reading a parse error

When you paste invalid JSON into a strict parser, you typically get something like:

Unexpected token } in JSON at position 42

The position is a character offset from the very start of the string, not a line number — which is why it's painful to find by eye in a large payload. That's the exact problem a proper JSON tool solves: it converts that raw character offset into a line and column you can actually jump to. Our JSON Validator does this automatically.

Formatting vs. validating vs. minifying — different jobs

• Formatting re-indents already-valid JSON so nested structures are easy to scan. Use JSON Formatter when you have a minified API response and want to read it.
• Validating just checks correctness and points at the problem. Use JSON Validator when something is broken and you need to find where.
• Minifying strips all the whitespace back out, for when you want the smallest possible payload to store or transmit. Use JSON Minifier before saving JSON into a database column or a URL parameter.

All three do the same fundamental thing under the hood — parse, then re-serialize — just with different output shapes.