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.