Why Your JSON Keeps Breaking (And How to Fix It Fast)

You paste a JSON config into your app and hit SyntaxError: Unexpected token. You scan 60 lines of curly braces, counting quotes by eye. Five minutes later you spot it — a trailing comma on line 47. Sound familiar?

JSON is ruthlessly strict. No trailing commas. No comments. No single quotes. No unquoted keys. Even one character out of place produces a completely opaque error message that points you to the wrong line half the time. This post covers the four JSON mistakes that cause 90% of parse failures, how to spot them instantly, and how to stop wasting time on them.

The Four Most Common JSON Errors

1. Trailing Commas

This is the most frequent offender, especially if your JSON was hand-written or copied from a JavaScript object literal.

Broken:

{
  "name": "Alice",
  "role": "admin",
  "active": true,
}

Fixed:

{
  "name": "Alice",
  "role": "admin",
  "active": true
}

The trailing comma after true is valid JavaScript but illegal JSON. Most parsers point you to the closing brace, not the offending comma, which sends you hunting in the wrong direction.

2. Single Quotes Instead of Double Quotes

Developers who spend most of their time in JavaScript or Python often reach for single quotes out of habit.

Broken:

{
  'username': 'bob',
  'permissions': ['read', 'write']
}

Fixed:

{
  "username": "bob",
  "permissions": ["read", "write"]
}

The JSON specification (RFC 8259) is explicit: strings must use double quotes. Single quotes are not valid, period.

3. Comments Embedded in JSON

If you copied a config from documentation or a README, it may include comments added for human clarity. JSON does not support comments.

Broken:

{
  // database settings
  "host": "localhost",
  "port": 5432,  /* default postgres port */
  "database": "myapp"
}

Fixed:

{
  "host": "localhost",
  "port": 5432,
  "database": "myapp"
}

Strip every // line comment and every /* */ block comment before parsing. If you need to annotate your configs, consider YAML or TOML — or adopt a _comment key as a convention.

4. JavaScript-Only Values

undefined, NaN, and Infinity are valid JavaScript but completely foreign to JSON. Only null, true, false, numbers, strings, arrays, and objects are allowed.

Broken:

{
  "count": NaN,
  "result": undefined,
  "ratio": Infinity
}

Fixed:

{
  "count": 0,
  "result": null,
  "ratio": null
}

These typically appear when serializing JavaScript objects that contain these special values — a common trap when using JSON.stringify() without a replacer function.

Stop Hunting for Errors by Eye

Reading JSON manually for syntax errors is a poor use of your attention. Paste your broken JSON into the JSON Formatter & Validator at jsonindenter.com and it will immediately highlight exactly which line is wrong and why. It also re-indents the output so that nested structures become readable at a glance — a lifesaver when someone hands you a 2KB single-line blob.

The validator catches all four of the errors described above and gives you a plain-English error message rather than the cryptic column-number output your runtime throws.

Comparing Two JSON Responses

Another common scenario: you have two versions of a JSON response — one from staging, one from production — and something is different but you can't tell what. Diffing them by eye across two editor tabs is tedious and error-prone.

The JSON Diff tool does a structural comparison of two JSON documents and highlights exactly which keys were added, removed, or changed in value. Because it understands JSON structure, it doesn't get confused by whitespace changes or key reordering — it shows you only what actually changed semantically.

Minifying for Production

Once your JSON is clean and validated, you may want to strip all whitespace before embedding it in a build artifact or sending it over the wire. The JSON Minifier removes all unnecessary whitespace in one click. For a 500-line formatted config file, the minified output is typically 3–5× smaller by byte count — a meaningful difference in payload-sensitive contexts like mobile APIs or edge functions.

A Practical Debugging Workflow

When JSON breaks in a project, this three-step process gets me to a fix in under two minutes:

1. Paste into the formatter — it shows the exact error location and corrects indentation so the structure is visible
2. Fix the flagged issue and validate again until the document is clean
3. If the JSON parses successfully but behavior is still wrong, use the diff tool to compare against the last known-good version line by line

This replaces what used to be ten minutes of manual scanning and guessing.

The Bigger Picture

Most JSON headaches come from the same handful of mistakes, and almost all of them come from editing JSON by hand or copying it from contexts that allow looser syntax — JavaScript objects, Python dicts, config files with comments. The fix isn't memorizing the spec; it's building a habit of running JSON through a validator before it ever reaches your parser.

What's your most painful "I spent an hour on a trailing comma" story? Drop it in the comments — I know I'm not the only one who's been there.

Free tools used in this post:

• JSON Formatter & Validator — paste broken JSON and get instant error highlighting with clean re-indentation
• JSON Diff — structural comparison of two JSON documents, shows exactly what changed semantically
• JSON Minifier — strips all whitespace from JSON for smaller payloads
• All tools — client-side, no sign-up, nothing leaves your browser