JSON looks simple until it isn't. A single missing comma or an extra trailing one can take down an API integration, and the resulting error messages aren't always helpful about where the problem actually is.

This guide covers how to format JSON so people can read it, the syntax errors that cause most parse failures, how to read a parser's error message, and the subtler problems — valid JSON that still produces wrong data. The rules come from RFC 8259, the standard that defines JSON.

Why pretty-printing matters

Minified JSON — everything on one line — is efficient to transmit but nearly impossible to debug by eye. Pretty-printing with consistent indentation turns a wall of characters into a structure you can actually scan: you can see nesting depth, spot where an array ends, and visually match opening and closing braces.

Compare the same data both ways:

{"user":{"id":1,"name":"Ana","roles":["admin","editor"]}}
{
  "user": {
    "id": 1,
    "name": "Ana",
    "roles": [
      "admin",
      "editor"
    ]
  }
}

The second version is exactly what JavaScript produces with JSON.stringify(data, null, 2). The third argument sets the indentation; per MDN, numbers above 10 are treated as 10, and you can pass a string such as "\t" to indent with tabs. Whitespace between tokens is insignificant in JSON, so a parser treats the one-line and indented versions identically.

The rule of thumb: minify for production payloads, pretty-print for anything a human needs to read — config files, API responses you're debugging, or documentation examples.

It's also worth knowing how much minifying actually saves once HTTP compression is involved. In one test payload we built — 500 near-identical user records — the 2-space version was 76,392 bytes against 48,891 minified, about 56% larger. After gzip, the two were 1,590 and 1,487 bytes, a difference of about 7%. Your data will compress differently, but the lesson generally holds: compression recovers most of the cost of whitespace.

The most common JSON syntax errors

How to read a parse error

A parser reports the position where it noticed something was wrong, which is often just after the actual mistake. Paste the trailing-comma example into Node.js 22 and you get:

Expected double-quoted property name in JSON at position 16 (line 1 column 17)

Position 16 is the closing brace, not the comma. After a comma, the parser expects another key, so it complains about the brace. The practical habit: when an error points at a location, look at the character just before it. The wording varies between browsers and runtimes, but the position is always the useful part.

Valid JSON that still causes bugs

Passing validation only means the syntax is right. These problems parse without complaint and then cause trouble later:

JSON.stringify({ a: undefined, b: () => 1, c: NaN, d: Infinity, e: new Date(0), f: [undefined] })
// '{"c":null,"d":null,"e":"1970-01-01T00:00:00.000Z","f":[null]}'

The undefined and function properties vanish, NaN and Infinity become null, and the date turns into a string that won't become a date again when parsed. A BigInt value throws an error instead.

Formatting conventions worth standardizing

A habit worth building

Before sending JSON into a system that will silently accept or reject it, run it through a validator that gives you a clear parse error with a location — not just "invalid JSON" with no other context. Catching a typo before it ships saves the far more annoying debugging session of tracing a 400 error back to a missing bracket three services downstream.

A short pre-flight checklist:

  1. Validate the payload and fix errors by looking just before the reported position.
  2. Check for Windows paths, regex patterns, or anything else containing backslashes.
  3. Confirm large numeric IDs are strings.
  4. Pretty-print to review, then minify (or rely on gzip) for transport.

When a payload changes and you can't see why, format both versions the same way and compare them with the Text Diff tool. It compares line by line, so a minified payload shows up as one changed line, while pretty-printed versions make the real change jump out. And if the JSON you're inspecting arrived inside a login token, the JWT Decoder will extract and format the header and payload for you.

Try it yourself

Paste JSON to validate, pretty-print, or minify it instantly — errors show exactly what failed.

Open JSON Formatter →

If your workflow also involves passing data through URLs, our URL Encoder handles the percent-encoding that JSON payloads often need when embedded in query strings.

Frequently asked questions

Can JSON files contain comments?

No. Standard JSON has no comment syntax, so a strict parser rejects both // and /* */ comments. Formats such as JSONC and JSON5 allow comments and are common in config files, but they need a parser that supports them — or the comments must be stripped before the file is read as plain JSON.

Should I indent JSON with 2 spaces or 4?

Either is fine. Whitespace between tokens is insignificant in JSON, so parsers treat both identically. Pick one per project and let a formatter enforce it; 2 spaces keeps deeply nested data from drifting too far to the right.

Why did a large ID number change after I parsed my JSON?

JavaScript parses JSON numbers as 64-bit floating-point values, which can only represent integers exactly up to 9,007,199,254,740,991. Larger values are rounded, so 9007199254740993 becomes 9007199254740992. Sending large IDs as strings avoids the problem.