Why unreadable JSON is a daily problem

Every API response, config file and log line is JSON. Minified, it is a single wall of characters; pretty-printed, the same data becomes something you can scan in two seconds. The data is identical — only the whitespace differs — which is why “formatting” is one of the most common developer searches on the web.

This guide covers what formatting actually does, how validation works, and the handful of errors responsible for almost every “invalid JSON” message you will see.

Formatting vs minifying vs validating

Operation What it changes When to use it
Format (pretty-print) Adds indentation and line breaks Reading, reviewing, debugging
Minify Removes all optional whitespace Sending payloads, storing configs
Validate Changes nothing; reports syntax errors Before you ship a config or a request body

All three are one click apart in the JSON formatter, which runs entirely in your browser.

What actually counts as valid JSON

JSON has a very small grammar, and it is stricter than JavaScript:

  • Keys must be double-quoted strings
  • Strings must use double quotes — single quotes are invalid
  • No trailing commas, ever
  • No comments (// or /* */)
  • Only these value types: object, array, string, number, true, false, null
  • Numbers cannot have leading zeros, and NaN/Infinity are not valid

If you have used JSON5, JSONC (VS Code config files) or a JavaScript object literal, some of your habits are illegal in JSON.

The five errors that cause most failures

1. Trailing comma

{
  "name": "NavProject",
  "version": "1.0",
}

The comma after "1.0" is the single most common cause of invalid JSON.

2. Single quotes

{ 'name': 'NavProject' }

Valid JavaScript, invalid JSON.

3. Unquoted keys

{ name: "NavProject" }

Also valid JavaScript, also invalid JSON.

4. Comments

Developers add // TODO to a config file and then wonder why the app refuses to start. Standard JSON has no comment syntax — strip them, or use a format that allows them.

5. Truncated or concatenated payloads

Two objects pasted together, or a log line that was cut mid-string. This is the error you will see most often when scraping logs.

How to read a JSON error message

Browser and Node error messages look like this:

Unexpected token } in JSON at position 84

The position is a character offset from the start of the string, not a line number. Convert it by counting characters, or let a tool do it: the formatter reports the failure as line N, column M, which is what you actually need to fix it.

A workflow that works

  1. Paste the raw payload into the JSON formatter
  2. Press Validate to confirm it parses at all
  3. Press Format and read the structure — this is usually where you spot the missing key or the wrong nesting
  4. Fix the source, then Minify only when you are sending or storing it
  5. Keep the pretty version in your repo; minify at build or transport time

Common questions about size

Minifying typically saves 10–30% depending on nesting depth — rarely enough to matter on its own, because gzip over the wire compresses far more. The real reason to minify is consistency: you avoid merge conflicts caused by whitespace and you keep payload sizes predictable.

FAQ

Does formatting change my data? No. Whitespace outside of strings is insignificant in JSON, so formatting and minifying are lossless.

Can JSON have duplicate keys? Technically the spec does not forbid it, but the behaviour is undefined — most parsers keep the last value. Avoid duplicates.

Why does my JSON work in JavaScript but not in a validator? Because you are not writing JSON, you are writing a JavaScript object literal. Convert it with JSON.stringify(obj) first.

Does the tool upload anything? No — parsing happens locally with the browser’s own JSON parser. You can even use it offline.