JSON Formatting and Validation: Common Errors and How to Fix Them

JSON looks simple because the syntax is small.

That is also why small mistakes can stop a payload from parsing.

A missing quote, trailing comma, unescaped line break, or wrong data type can be enough to make otherwise useful JSON invalid.

The current Internet Standard for JSON is RFC 8259, which defines the format and addresses interoperability issues between implementations.

The good news is that most JSON errors are predictable.

What valid JSON looks like

A basic JSON object looks like this:

{
  "name": "PixelToFile",
  "free": true,
  "tools": 226
}

JSON has a relatively small set of value types:

• String
• Number
• Object
• Array
• Boolean
• `null`

A JSON object uses name/value pairs.

Error 1: trailing commas

This is one of the most common errors for developers coming from JavaScript.

This is JavaScript-like, but invalid JSON:

{
  "name": "PixelToFile",
  "tools": 226,
}

The comma after `226` must be removed:

{
  "name": "PixelToFile",
  "tools": 226
}

Some programming languages tolerate trailing commas. Strict JSON parsers do not treat JSON as an extension of those languages.

Error 2: using single quotes

This is another common mistake:

{
  'name': 'PixelToFile'
}

JSON strings use double quotes:

{
  "name": "PixelToFile"
}

That includes property names as well as string values.

Error 3: unescaped quotation marks

Suppose you want to include this sentence:

He said "hello".

The quotation marks have to be escaped inside a JSON string:

{
  "message": "He said \"hello\"."
}

Without the backslashes, the parser sees the inner quote as the end of the string.

Error 4: actual line breaks inside a string

This is invalid:

{
  "message": "Line one
  Line two"
}

Use the escaped newline sequence:

{
  "message": "Line one\nLine two"
}

The backslash is part of the JSON representation.

Error 5: using comments

JSON does not define comments as part of the data format.

This is invalid:

{
  // User account
  "name": "Nehal"
}

If you need comments, put explanatory information somewhere else or use a separate format designed to support comments.

Error 6: confusing strings and numbers

These two values are not the same type:

{
  "age": 30
}

and:

{
  "age": "30"
}

The first is a number.

The second is a string containing two characters.

Whether that difference matters depends on the API receiving the JSON.

Error 7: leading zeros and number syntax

Developers sometimes write numbers using conventions from other languages.

Be careful with values that look like octal or contain unsupported numeric notation.

JSON's number syntax is deliberately defined and should not be treated as "whatever JavaScript happens to accept."

When in doubt, use a JSON validator rather than guessing.

Error 8: using `undefined`, `NaN`, or `Infinity`

These are JavaScript values, not JSON values.

For example:

{
  "result": undefined
}

is invalid JSON.

The same goes for:

{
  "value": NaN
}

A common approach is to represent missing data with `null` when that matches the application's data model.

Error 9: invisible characters and encoding issues

Sometimes a parser error appears near the beginning of an otherwise correct document.

Encoding problems can be responsible.

A byte order mark (BOM) or unexpected invisible character can cause trouble in systems that expect a specific representation.

When debugging a mysterious parse failure, inspect the actual bytes or save the document using a standard UTF-8 encoding.

JSON objects and arrays

Objects use braces:

{
  "name": "Nehal",
  "country": "Pakistan"
}

Arrays use square brackets:

{
  "tools": [
    "Merge PDF",
    "JSON Formatter",
    "ROAS Calculator"
  ]
}

Arrays can contain objects too:

{
  "tools": [
    {
      "name": "Merge PDF",
      "category": "PDF"
    },
    {
      "name": "JSON Formatter",
      "category": "Developer"
    }
  ]
}

Indentation does not determine validity, but good formatting makes errors much easier to find.

Formatting vs validation

These are related, but they are not the same operation.

**Formatting** changes how the JSON is displayed.

**Validation** checks whether the structure follows JSON syntax.

A formatter cannot make fundamentally invalid data magically correct.

A good debugging sequence is:

**Validate first**

→ fix the parser error

→ format the valid JSON

→ inspect the resulting structure

What about schemas?

Valid JSON does not automatically mean that the data is correct for an API.

For example, this is syntactically valid:

{
  "price": "free"
}

But an API may require:

{
  "price": 0
}

That is a schema/application-level rule rather than a basic JSON syntax rule.

This distinction matters when debugging API payloads.

A practical debugging method

When a large JSON document fails:

1. Read the exact parser error and line number.
2. Inspect the lines immediately before the reported location.
3. Check quotes and commas first.
4. Check whether a string contains unescaped characters.
5. Check braces and brackets.
6. Check data types.
7. Validate again.
8. Only then worry about the application schema.

Parsers often point to where they *noticed* the problem, not necessarily where the mistake was originally introduced.

For example, a missing closing quote may cause the parser to complain several lines later.

Formatting for human review

Once the document validates, indentation makes a large difference.

Compare:

{"user":{"name":"Nehal","tools":226}}

with:

{
  "user": {
    "name": "Nehal",
    "tools": 226
  }
}

The second version is much easier to inspect.

Formatting is especially useful when reviewing nested configuration files and API responses.

Where PixelToFile fits

A JSON Formatter or Validator is most useful once you know whether the problem is syntax or application logic.

Use it to:

• validate a payload
• make minified JSON readable
• inspect nesting
• spot structural mistakes
• produce a clean copy for documentation

For sensitive payloads, pay attention to where processing occurs. A browser-native formatter can be preferable when you do not want to send private data to a remote parsing service.

Final takeaway

JSON has a small grammar, but it expects that grammar to be followed exactly.

When a payload fails, start with the basics:

**double quotes → commas → brackets/braces → escaped characters → valid JSON value types**

Then distinguish syntax from the separate question of whether an API's schema accepts the structure.

That approach is usually faster than staring at a large payload and guessing.