JSON Arrays in Practice: Escaping, Types and Common Mistakes

6 min read · Updated 2026-08-04

JSON is small enough to learn in an afternoon and awkward enough to trip over for years. Most of the trouble comes from three places: escaping, type coercion, and error messages that point at the wrong line.

Escaping is the whole problem

A JSON string is delimited by double quotes, which immediately raises the question of what happens when the value itself contains one. The answer is a backslash: "He said \"hello\"". Simple enough — until the value contains a backslash, which must itself be escaped as \\, and now you are counting backslashes.

Windows file paths are where this bites hardest. The path C:\Users\Alberto becomes "C:\\Users\\Alberto" in JSON. Miss one and the parser sees \U, which is not a valid escape sequence, and rejects the document.

Control characters have their own escapes: \n for a newline, \t for a tab, \r for a carriage return. A literal newline inside a JSON string is invalid, which surprises people who paste multi-line text into a value and cannot see why it fails.

The practical conclusion is that hand-writing JSON containing arbitrary text is a bad use of your time. Any generator — including the browser's own JSON.stringify, which is what this site's converter uses — handles every one of these cases correctly and takes no longer than typing the brackets yourself.

The trailing comma

JSON does not allow a trailing comma after the last element. JavaScript does, and so do most programming languages people are used to, which is why this is comfortably the most common syntax error in hand-written JSON.

["a", "b", "c",]   // invalid JSON
["a", "b", "c"]    // valid

It is worth knowing that many editors and parsers are lenient about this, including some that call themselves JSON parsers. A file that loads fine in your editor can still be rejected by a strict parser at the other end, so "it worked locally" is not evidence that the JSON is valid.

Numbers, strings and lost information

JSON has a number type, and using it is often a mistake. The moment a value becomes a number, three things can happen to it: leading zeros are dropped, the number of decimal places is normalised, and very large integers lose precision.

That last one is worth stating precisely, because it produces bugs that survive for months. JSON numbers are typically parsed into IEEE 754 double-precision floats, which represent integers exactly only up to 2⁵³ — about 9 quadrillion. Beyond that, values silently round. Snowflake IDs used by several large platforms exceed this, which is exactly why those APIs return IDs as strings alongside the numeric version.

The test is simple: would you ever perform arithmetic on this value? A price, a quantity, a temperature — yes, those are numbers. An account number, a postcode, a phone number, a version string, a database ID — no. Those are identifiers that happen to be written with digits, and they belong in strings. Being able to sort them numerically is not a good enough reason to convert.

Arrays of what?

JSON permits an array to contain mixed types, and there are situations where that is genuinely the right model. In most cases, though, a mixed array is a sign that something upstream is inconsistent — a field that is sometimes a string and sometimes null, or a number that occasionally arrives as text.

The cost is paid by every consumer of the data, who now has to handle each possible type. If you control the producer, pick one type per position and stick to it. If you do not, normalise on arrival rather than scattering type checks throughout your code.

Reading a parse error

A message like Unexpected token } in JSON at position 1247 is more useful than it looks, once you know how to read it. The position is a character offset from the start of the document, not a line number, and — crucially — it is where the parser gave up, not where the mistake is. A missing comma at position 400 is not detected until the parser reaches something that cannot follow what it has already read.

So the rule is: look at the reported position, then scan backwards for the actual error. The usual suspects, in order of frequency, are a trailing comma, a missing comma between elements, an unescaped quote inside a string, and a single quote used where JSON requires a double.

JSON is not JavaScript

The name suggests otherwise, but JSON is a strict subset with meaningful differences. Keys must be double-quoted strings — {name: "x"} is valid JavaScript and invalid JSON. Single-quoted strings are not allowed. Comments are not allowed, which is a genuine limitation for configuration files and the reason formats such as JSON5 and JSONC exist. undefined, NaN and Infinity have no representation at all.

If you need comments in a config file, you need a different format — YAML, TOML, or a JSON variant that explicitly supports them. Adding // to a .json file will work in your editor and fail in production, which is the worst combination of outcomes.