The 5 Most Common JSON Mistakes (and How to Catch Them Before Production)

JSON is supposed to be the easy format. It is plain text, it is human-readable, it is the lingua franca of every API on the web. So why does it keep breaking in production?

Because JSON has a small number of rules that almost every other similar format (JavaScript, Python, YAML, TOML) does not enforce. Things that look fine to a human reading the file turn out to be fatal syntax errors for a parser. The same five mistakes show up in every broken JSON file I have ever debugged. This post is what they are, why parsers reject them, and how to catch them before they ship.

The Uttir JSON Validator and JSON Formatter catch all five in your browser, with line and column numbers so you can find the bug fast.

Mistake 1: trailing commas

JavaScript allows trailing commas in object and array literals. Python allows them. JSON does not.

{
  "name": "Alice",
  "age": 30,
  "country": "US",  <-- this trailing comma breaks the JSON
}

The parser sees the } and expects the end of the object. Instead it sees another comma. It throws Unexpected token } at position 87 or similar.

This is the most common JSON mistake in the wild, because the exact pattern (a trailing comma after the last property) is so natural when adding items to a list. A developer adds a new property, copies the comma pattern from the previous line, and the file is invalid.

How to catch it. Any JSON linter will flag it. Most editors (VS Code, JetBrains) flag it inline. The Uttir JSON Formatter will throw a parse error with the line and column number when it encounters a trailing comma.

Mistake 2: unquoted keys

In JavaScript, an object literal can have unquoted keys:

{
  name: "Alice",
  age: 30
}

This is valid JavaScript. It is not valid JSON. JSON requires every key to be a double-quoted string:

{
  "name": "Alice",
  "age": 30
}

This mistake happens when someone copies a JavaScript object literal directly into a .json file or a JSON template, or when they use a templating language (Handlebars, Liquid, Jinja) that strips the quotes for ergonomic reasons. The file is rendered correctly in the browser but breaks when a real JSON parser tries to load it.

How to catch it. A JSON validator. The Uttir JSON Validator flags this with the exact line and column.

Mistake 3: single quotes instead of double quotes

JSON requires double quotes for strings. Always. Single quotes are not allowed.

{
  "name": 'Alice',  <-- single quotes, invalid JSON
  "age": 30
}

This is valid Python (with the right context), valid JavaScript, but not valid JSON. The parser sees the ' and expects a ".

Where this mistake comes from: Python's json.dumps uses double quotes by default, but if you mix in a string constructed with str.format or f-strings, single quotes can leak in. JavaScript template literals that get serialised to JSON will use double quotes correctly, but a hand-edited file might not.

How to catch it. Any JSON validator. The error message is usually clear: Expected double-quoted property name or Unexpected token '.

Mistake 4: comments in JSON

JSON does not support comments. There is no comment syntax. Not //, not /* */, not #.

{
  // this is a comment, but JSON does not allow it
  "name": "Alice",
  "age": 30
}

This is one of the most-debated JSON limitations, and there are extensions (JSON5, JSONC, JSON-with-comments) that allow them. But plain JSON does not. The official JSON specification (RFC 8259) is explicit: comments are not part of the format.

Where this comes from: developers used to writing JavaScript or YAML add a quick comment to explain a tricky field, then commit the file. The file is invalid; any parser that follows the spec will reject it.

How to catch it. A validator. If you need to comment a JSON file, put the comments in a sibling file (a README or a separate schema file) or use a format that supports comments (JSON5, JSONC). The Uttir JSON to YAML tool is a quick way to convert JSON to YAML if you want comments in the file (YAML supports them).

Mistake 5: NaN, undefined, Infinity, and other non-standard values

JSON supports strings, numbers, booleans, null, arrays, and objects. That is it. Not NaN. Not undefined. Not Infinity. Not dates (no native date type; use an ISO 8601 string). Not functions. Not regular expressions.

{
  "name": "Alice",
  "age": NaN,         <-- invalid, NaN is not a JSON value
  "score": Infinity,  <-- invalid
  "deleted": undefined  <-- invalid
}

This mistake usually comes from JSON.stringify in JavaScript. By default, JSON.stringify silently drops undefined properties and converts NaN and Infinity to null in some implementations. If you have a buggy or non-standard serialiser, the output can contain literal NaN or undefined strings, and the file will be invalid.

The fix is to either filter these values out before serialising, or to use a robust serialiser that handles them correctly.

How to catch it. A validator. The error message points to the literal NaN or undefined in the file.

How to never ship a broken JSON file

The pattern that prevents all five of these is the same: lint your JSON in CI, before the file ever reaches production. A few practical setups:

• Pre-commit hook. A hook that runs jsonlint or ajv (with a schema, if you have one) on every changed .json file. Catches the bug before it even gets to a pull request.
• CI step. A step in your continuous integration pipeline that runs the same check on every commit. Catches the bug before it gets merged.
• Schema validation. If you have a JSON Schema for the file, validate against the schema. This catches more than syntax (it catches missing required fields, wrong types, invalid enums), but it requires the schema to exist first.
• Editor integration. A linter that runs in your editor, inline, as you type. Catches the bug before you even save the file. VS Code, JetBrains, and most modern editors have JSON linting built in.

For one-off validation (a JSON file you are debugging, a payload from a third-party API, a snippet from Stack Overflow), the Uttir JSON Validator and JSON Formatter do the same job in the browser. Paste the file, see the line and column of the bug, fix it, paste it back.

The JSON-LD Generator is a good companion if you are shipping JSON-LD for SEO; the rules for JSON-LD are the same as JSON, plus a few schema-specific rules that JSON-LD validators check.