The five errors that break JSON
JSON looks like a JavaScript object literal, but the parser is far stricter. Almost every "unexpected token" message comes down to one of these:
| Mistake | Wrong | Right |
|---|---|---|
| Trailing comma | [1, 2, 3,] | [1, 2, 3] |
| Single quotes | {'a': 1} | {"a": 1} |
| Unquoted key | {a: 1} | {"a": 1} |
| Comments | {} // note | (remove them) |
| Leading zero / hex | {"n": 0x1F} | {"n": 31} |
Gotcha — big numbers lose precision. JSON has one number type backed by a 64-bit float, so integers above 9,007,199,254,740,991 (253−1) silently round. For IDs and money, send them as strings and parse on the other side.
The values JSON permits
Beyond avoiding the errors above, it helps to know the whole vocabulary: a JSON value is an object, an array, a string, a number, true, false or null — and nothing else. There are no dates, no functions and no undefined. A date is just a string by convention (usually ISO 8601), and a "JSON object" is purely data, never behaviour.
Never parse JSON with eval(). It will execute any code hidden in the string. Every language ships a safe parser — JSON.parse, json.loads — and this tool parses locally without running anything.
When to format and when to minify
Format (pretty-print) while reading, debugging, or committing a config to version control — indentation makes structure and diffs readable. Minify (strip whitespace) for transport, so responses and files travel smaller and faster. The data is identical either way, so switching back and forth is safe.
From minified to readable
An API response usually arrives as one dense line:
{"user":{"id":7,"name":"Ada","roles":["admin","editor"]},"active":true}Formatting exposes the shape — a user object with an id, name and roles array, plus a top-level active flag — without changing a single value.
Why your config file isn't really JSON
Strict JSON bans comments and trailing commas, which is fine for data on the wire and painful for configuration a human edits. So a whole family of relaxed variants grew up around it. JSONC ("JSON with comments") is what VS Code's settings and tsconfig.json actually use — looks like JSON, allows // comments and trailing commas. JSON5 goes further with unquoted keys, single quotes and hex numbers. They're great for configs, but they are not interchangeable with strict JSON: hand a JSONC file with comments to a vanilla JSON.parse and it throws. If a parser is rejecting a config that "looks fine", a stray comment is usually why.
There's also JSON Lines (also called NDJSON): one JSON object per line, no wrapping array. Logs and data exports love it because you can append a record without rewriting the file and process it one line at a time instead of loading gigabytes into memory. It isn't valid JSON as a whole — each line is.
Precision and prototype pollution
JSON has a single number type backed by a 64-bit float, so any integer past 9,007,199,254,740,991 silently loses precision. A 64-bit database ID or a Twitter snowflake ID will arrive subtly wrong if you parse it as a number, which is why APIs that care send big IDs as strings. The other quiet hazard is security: a key literally named __proto__ in untrusted JSON has been used to pollute JavaScript object prototypes and, in a few real CVEs, escalate to worse. The fix isn't exotic — use a current runtime, validate untrusted input against a schema, and never feed it to anything that builds objects by blindly copying keys.
Should I use YAML or TOML instead of JSON for config?
For human-edited config, often yes. YAML and TOML allow comments and are easier to read, which is why tools adopt them. JSON's strength is being a universal data-interchange format that every language parses identically — great on the wire, less pleasant to hand-edit.
Why does my tsconfig.json have comments if JSON can't?
Because it isn't strict JSON — it's JSONC, a relaxed variant that allows comments and trailing commas. Many config files use JSONC or JSON5. A standard JSON.parse would reject them, so editors and build tools use lenient parsers.
Does formatting change my data?
No. Indentation and line breaks are cosmetic. Pretty-printing and minifying produce identical data — only the whitespace differs.
Should I store JSON pretty or minified?
Pretty for files humans read or that live in version control; minified for data sent over the network. Many setups keep configs pretty and minify API payloads.
Is my JSON sent anywhere?
No. Parsing, formatting and validation all run in your browser with the built-in JSON.parse. Paste secrets without worry — nothing leaves the page.
What indentation does Format use?
Two spaces, the most common default for JSON in config files and APIs. Minify removes all whitespace for the smallest payload.
Why does it reject comments?
The JSON spec has no comments. If your file has them it is really JSONC or JSON5 — strip the comments first, or use a parser built for those formats.