5 Common JSON Mistakes and How to Fix Them

JSON is deceptively simple — it looks just like a JavaScript object literal, which trips up developers constantly. The format has very strict rules, and most parsers give terse error messages like "Unexpected token" or "Unterminated string" that don't immediately tell you what went wrong or where. This article covers five common mistakes, with clear examples and fixes for each.

1. Trailing commas

This one catches developers who write JavaScript, where trailing commas are perfectly legal (and even encouraged by style guides). JSON does not allow a comma after the last element of an object or array.

// ❌ Invalid JSON — trailing comma after "Hyderabad"
{
  "cities": ["Mumbai", "Delhi", "Hyderabad",]
}

// ✅ Valid JSON
{
  "cities": ["Mumbai", "Delhi", "Hyderabad"]
}

The same rule applies to object properties. A trailing comma is simply not in the JSON grammar, and the mainstream strict parsers reject it — JSON.parse in JavaScript and Python's json module both refuse it. Note that RFC 8259 §9 does permit a parser to accept extensions, which is why JSON5 and JSONC tooling can let it through; "a parser accepted it" is not evidence that the document is valid JSON.

// ❌ Invalid — trailing comma after the "city" field
{
  "name": "Priya",
  "city": "Pune",
}

// ✅ Valid
{
  "name": "Priya",
  "city": "Pune"
}

Fix: Remove the comma after the last item. If you find yourself doing this frequently, add a JSON linter to your editor. VS Code highlights trailing commas in .json files automatically.

2. Single quotes instead of double quotes

JavaScript allows both single quotes (') and double quotes (") for strings. JSON only allows double quotes — both for keys and for string values. Using single quotes is a very common mistake when manually writing JSON.

// ❌ Invalid — single quotes everywhere
{
  'name': 'Arjun',
  'role': 'developer'
}

// ✅ Valid — double quotes throughout
{
  "name": "Arjun",
  "role": "developer"
}

Keys must also be quoted — bare identifiers like {name: "Arjun"} are not valid JSON even though they are valid JavaScript object syntax.

3. Unescaped special characters in strings

JSON strings cannot contain a literal double quote, a literal backslash, or any control character in the range U+0000 to U+001F — that is every control character, not a selection of them, so a literal newline or tab is out as well. They must be escaped with a backslash sequence. RFC 8259 §7 defines nine:

• \" — double quote
• \\ — backslash
• \/ — forward slash (optional)
• \b — backspace (U+0008)
• \f — form feed (U+000C)
• \n — newline
• \r — carriage return
• \t — tab
• \uXXXX — unicode escape

// ❌ Invalid — literal newline and unescaped double quote inside string
{
  "message": "Hello "World"
  How are you?"
}

// ✅ Valid — escaped quote and \n for newline
{
  "message": "Hello \"World\"\nHow are you?"
}

This comes up frequently when the JSON contains file paths on Windows (backslashes must be doubled: C:\\Users\\dev) or when it contains SQL strings with embedded quotes.

4. Comments in JSON

JSON does not support comments. Early drafts did; Douglas Crockford (JSON's creator) took them out, and he has explained why: "I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability." Many developers accustomed to YAML or JSONC (JSON with Comments, used in VS Code's settings) are surprised to discover that standard JSON parsers reject any comment syntax.

// ❌ Invalid — // comments are not allowed in JSON
{
  // Database configuration
  "host": "localhost",
  "port": 5432, // default PostgreSQL port
  "database": "myapp"
}

// ✅ Valid — no comments; use descriptive key names instead
{
  "db_host": "localhost",
  "db_port": 5432,
  "db_name": "myapp"
}

If you need comments in configuration files, consider using YAML (which supports comments with #) or JSONC. Spring Boot's application.properties and application.yml both support comments natively.

5. Incorrect number formats

JSON numbers follow strict formatting rules. Leading zeros, plus signs, and certain special values that JavaScript supports (like Infinity and NaN) are not valid JSON.

// ❌ Invalid number formats
{
  "quantity": 0777,        // leading zero not allowed
  "positive": +5,          // explicit plus sign not allowed
  "not_a_number": NaN,     // NaN is not a JSON value
  "infinity": Infinity     // Infinity is not a JSON value
}

// ✅ Valid
{
  "quantity": 777,
  "positive": 5,
  "large": 1.5e10
}

If your backend returns NaN or Infinity as part of a JSON response (this happens with some Java libraries when a Double.NaN is serialised), a strict parser such as JSON.parse will throw. Not every parser will: Python's standard library json module accepts NaN and Infinity on input and emits them on output by default, which is often how they end up in a payload in the first place — pass allow_nan=False to json.dumps and it raises instead. The fix is to handle these values server-side before serialisation — replace with null or omit the field.

Quick checklist for debugging JSON errors

1. Remove all trailing commas after the last item in arrays and objects.
2. Replace all single quotes with double quotes for both keys and values.
3. Ensure all keys are quoted strings — no bare identifiers.
4. Escape any double quotes, backslashes, or newlines inside string values.
5. Remove all comments (// and /* */).
6. Replace NaN, Infinity, and undefined with null.
7. Paste into a JSON validator to pinpoint the exact error line and character.

Tools that help

Rather than hunting for these errors manually, use a JSON validator that highlights the exact error location. Most modern editors (VS Code, IntelliJ IDEA) also highlight JSON syntax errors in real-time. For REST API responses, browser DevTools' Network tab shows response bodies with syntax highlighting that makes malformed JSON immediately visible.