Guide

Common errors when writing JSON

Identify and fix invalid commas, quotes, comments, escapes, numbers, and closings with before and after JSON examples.

by Tools in a Tab · Published on · Reviewed on

Short answer

Many JSON errors boil down to a few patterns: a separator that missing or extra, a poorly delimited string, an extension taken from JavaScript or a structure that remained incomplete. Recognizing the pattern allows you to correct the cause without rewriting the entire document.

This page is a reference to compare incorrect entries with your form valid. If you need to know the first diagnosis, the line and the context of your own text, use the JSON validator. If you still do not know how to interpret that location, see the procedure to validate JSON and locate the error.

Quick reference

Pattern Usual track Minimal correction
Final comma There is a , before ] or } Remove the comma
Missing comma Another property or element starts without a separator Add , between the values
Missing colon The value appears immediately after the name Add : between name and value
Unquoted property The name looks like a JavaScript identifier Enclose it in "
Single quotes The string or property uses ' Use double quotes
Invalid escape A backslash starts an unknown sequence Escape the slash or use a JSON escape
Comment // or /* ... */ appears Remove comment
Unsupported value undefined, NaN or Infinity appears Model the data with JSON values
Invalid number There is a leading zero or missing digits Correct the number or use a string
Unexpected ending Missing value or closure Complete the structure
Extra content There are two consecutive root values Keep one or group them

Parsers do not have to word their messages the same way. The reported position may be the character where parsing can no longer continue even when the cause is immediately before it.

Separators: commas and colons

The colon separates a property’s name from its value. Commas separate members of an object or elements of an array. They are not interchangeable and a comma never closes a list.

A comma just before the closing

This list has a comma after its last element:

{"roles":["editor","lector",]}

JSON does not support trailing commas. The valid version ends the last value and close the array directly:

{
  "roles": ["editor", "lector"]
}

The same rule applies to objects: there cannot be a comma before }.

Missing comma between properties

Here "port" starts without a comma after the previous member:

{"host":"localhost" "port":8080}

The fix is ​​between "localhost" and the following property:

{
  "host": "localhost",
  "port": 8080
}

The parser can point to the beginning of "port" because that is the point where it discovers that it cannot continue. The missing character is immediately before it.

The colon is missing

In an object, the name must be followed by a colon before the value:

{"modo" "seguro"}

The correct way is:

{
  "modo": "seguro"
}

A short rule helps differentiate them: : matches a name with its value; , separate that pair from the next.

Properties, quotes and strings

JSON looks like JavaScript object notation, but it doesn’t accept all of its abbreviated forms. Both property names and strings are delimited with double quotes.

A property name does not have quotes

This name could work as an identifier in JavaScript, but it is not a JSON string:

{modo:"seguro"}

It must be written between double quotes:

{
  "modo": "seguro"
}

The rule also applies to numeric or hyphenated names: within a JSON object, every property name is a string.

Single quotes have been used

Single quotes do not delimit strings or properties in JSON:

{'active':true}

The valid version uses double quotes:

{
  "active": true
}

It is not advisable to replace all single quotes automatically. A apostrophe can be part of the text and does not need to be converted:

{
  "message": "The input is open"
}

A backslash starts an invalid escape

In a string, the backslash \ starts an escape sequence. That’s why this path contains \d and \e, which are not JSON escapes:

{"path":"C:\data\input"}

To represent a literal backslash you have to write two:

{
  "path": "C:\\data\\input"
}

After parsing the JSON, each \\ represents a single bar in the value. JSON also supports short escapes such as \n, \t, \r, \b, and \f, in addition of \" for an inner quote and \uXXXX for a Unicode unit.

A line break or tab literal within a string is a character of control and must be escaped. Outside the chains, the Spaces, tabs, and line breaks can function as spaces in white.

Forms of JavaScript that JSON does not support

A file may look like JSON and actually use its own extensions. JavaScript, JSON5, JSONC or some configuration tool. An analyzer permissive can accept them, but that doesn’t make them interoperable JSON.

Comments

JSON does not define line or block comments:

{
  "port": 8080, // HTTP port
  "seguro": false
}

If the comment only documents the file, the correction is to remove it:

{
  "port": 8080,
  "seguro": false
}

If the note is to be part of the data, it could be modeled as a property only when the receiving system allows it. Add a property "comentario" on its own may breach the contract of an API.

undefined, NaN and Infinity

These values ​​exist in JavaScript, but are not part of the JSON grammar:

{"resultado":NaN,"opcional":undefined}

JSON supports objects, arrays, strings, numbers and only literals true, false and null. A possible representation would be:

{
  "resultado": null,
  "opcional": null
}

null is not an automatic replacement. According to the meaning of the data, It may be correct to use null, omit the property, or represent the state of another way. The decision belongs to the contract of the system that will receive the document.

Numbers that do not comply with grammar

JSON numbers are written in base ten. They may include a negative sign, a fraction and an exponent, but do not admit leading zeros unless the whole number is zero.

This value is not valid as a number:

{"intentos":03}

If it represents a quantity, the zero is removed:

{
  "intentos": 3
}

If 03 is a code and the zero has meaning, it must be preserved as text:

{
  "intentos": "03"
}

A fraction needs at least one digit after the period and an exponent needs digits after e or E. That’s why 1. and 2e are not numbers either. Complete JSON. The leading sign + is not supported.

Incomplete document or with more than one root

The entire JSON text contains a single root value. That value must be finished before the end of the document and cannot be followed by a second independent value.

Document ends before completing value

Here an array is opened, but no elements are added or the array is closed. structure:

{"items":[

If the intention was to render an empty list, the minimum fix is:

{
  "items": []
}

An unexpected ending can also indicate an unclosed string, a value that missing after : or pending closure of an object. Complete the structure according to actual data; do not add random closures until the analyzer stops to show an error.

There are two consecutive root values

These are two separate objects without any common container:

{"ok":true}{"ok":false}

If both belong to the same document, they can be grouped in an array:

[
  {
    "ok": true
  },
  {
    "ok": false
  }
]

Another solution may be to keep only one or process each document by separate. Grouping them is only correct if the receiver expects a list.

Three cases that are not syntax errors

Avoiding these false positives is as important as recognizing a comma or a incorrect quote.

A root value can be primitive

"text", 42, true, and null are valid JSON documents. An API can require that the root be an object or an array, but that is a rule of your contract, not the general JSON syntax.

Allowed blank space is valid

Spaces, tabs, carriage returns, and line breaks may appear outside the strings at the points allowed by the grammar. Format a document changes its presentation, not its validity.

Duplicate names are a different problem

This text complies with the grammar, although it repeats the same name:

{
  "status": "pending",
  "status": "shipped"
}

RFC 8259 recommends that object names be unique because different Receivers can keep the first value, the last value, all of them, or even reject the document. The native validator can accept it, while the Tools in a Tab converters reject duplicate names so as not to produce a ambiguous result.

Check the correctness

After recognizing a pattern, change only the identified cause and double check the entire document. The JSON validator preserves your input and shows the first problem with line, column and context directly in this tab.

When the result is already valid, you can use the JSON formatter to improve readability or generate a compact version. Valid syntax does not guarantee for an API to accept data: required properties, types, formats and Business rules should be reviewed in your documentation or JSON Schema.

Technical reference

The grammar and interoperability recommendations used in this guide are defined in RFC 8259. The incorrect examples are have checked against the Tools in a Tab validator and the fixes against the native JSON parser.