10 Common JSON Mistakes That Break Your Code (and How to Avoid Them)

JSON looks forgiving, but it is one of the strictest data formats developers use every day. The specification is deliberately tiny, which means there are very few legal ways to write it and a great many ways to get it wrong. A single trailing comma, a curly quote pasted from a document, or one missing bracket is enough to make a parser reject the entire payload with a cryptic error.

The good news: almost every broken JSON file fails for one of a handful of reasons. Once you recognize these patterns, you can spot them at a glance. Below are the ten most common JSON mistakes, why each one breaks your code, and the simple rule that keeps you out of trouble. If you want a refresher on the format itself first, see What Is JSON? and the JSON syntax rules.

1. Trailing commas

This is the single most common cause of invalid JSON, and it trips up experienced developers constantly. JavaScript object and array literals allow a comma after the last element, so the habit carries over, but the JSON specification does not permit it.

Invalid: {'a': 1, 'b': 2,} — note the comma after 2. Valid: {'a': 1, 'b': 2}. The same applies to arrays: [1, 2, 3,] is rejected, while [1, 2, 3] is fine.

Rule: a comma separates items, so it only ever appears between two items, never before a closing } or ]. The trailing comma JSON error most often appears when you reorder or delete properties and forget to clean up the punctuation.

2. Single quotes instead of double quotes

JSON requires double quotes for every string and every object key. Single quotes are not allowed anywhere, even though they are perfectly valid in JavaScript and Python.

Invalid: {'name': 'Ada'}. Valid: {"name": "Ada"}. This catches people who copy a Python dictionary or a JavaScript object straight into a JSON file. They look almost identical, but only the double-quoted version parses.

3. Unquoted keys

In JavaScript you can write { name: "Ada" } with a bare key. JSON does not allow this — every key must be a double-quoted string.

Invalid: {name: "Ada"}. Valid: {"name": "Ada"}. There are no exceptions, no shorthand, and no way to omit the quotes, even for keys that look like simple identifiers.

4. Comments

JSON has no syntax for comments. Neither // line comments nor /* block comments */ are valid, and adding either will break the parse. This frequently bites developers writing configuration files who want to annotate their settings.

If you genuinely need notes inside the data, add a string field for them instead, for example {"_comment": "staging values", "port": 8080}. For config files specifically, some tooling supports relaxed variants like JSON5 or JSONC, but those are not standard JSON and a strict parser will reject them.

5. Missing or mismatched brackets and braces

Every { needs a matching }, and every [ needs a matching ]. When they get out of balance — usually after copy-pasting a fragment or deleting a block — the parser reads past the end of the document looking for the close that never comes.

This produces the classic unexpected end of input message. An editor that highlights matching brackets makes these errors obvious; pasting the text into a free JSON formatter & validator pinpoints the exact line where the structure breaks.

6. Wrong value types

JSON values must be one of exactly six things: a string, a number, true, false, null, an object, or an array. Anything else is invalid.

The keywords true, false, and null are always lowercase. There is no undefined, no NaN, and no Infinity in JSON — use null when a value is absent.

7. Numbers that are not real numbers

JSON numbers follow strict rules that surprise people. Several things you can type in code are illegal:

• Leading zeros are not allowed: {"id": 007} is invalid; write 7.
• Leading plus signs are not allowed: +5 is invalid; write 5.
• Hex and octal are not allowed: 0xFF must be the decimal 255.
• A trailing or leading decimal point is not allowed: write 0.5 and 5.0, never .5 or 5..

If you need to preserve a value like a phone number, a zip code, or an ID with leading zeros, store it as a string: {"zip": "02139"}. As a number it would either be rejected or silently lose the zero.

8. Unescaped special characters in strings

Certain characters cannot appear literally inside a JSON string and must be escaped with a backslash. The most common culprits are the double quote itself and the backslash, followed by literal newlines and tabs.

Invalid: {"path": "C:\Users\Ada"} — each backslash needs escaping. Valid: {"path": "C:\\Users\\Ada"}. Likewise a quote inside a string becomes \", a newline becomes \n, and a tab becomes \t. A raw, unescaped line break inside a string is also invalid; it must be written as \n. These slip in most often when you build JSON by hand or with string concatenation instead of a serializer.

9. Building JSON by hand instead of serializing

Many of the mistakes above share one root cause: assembling JSON by gluing strings together. The moment a value contains a quote, a backslash, or a newline, your hand-built string breaks. The reliable fix is to let a real serializer do the work.

Use JSON.stringify(data) in JavaScript, json.dumps(data) in Python, or your language's standard library equivalent. These functions handle escaping, quoting, and commas correctly every time, which eliminates an entire class of json mistakes before they happen.

If you find yourself writing JSON with string concatenation, stop and reach for a serializer. It is faster and it is correct.

10. Encoding and invisible-character problems

Some of the most maddening errors come from characters you cannot see. The two usual suspects are a byte order mark (BOM) at the start of a file and curly or smart quotes that a word processor substituted for straight ones.

Smart quotes such as the ones a document editor inserts are not the straight " that JSON expects, so the parser treats your string as malformed even though it looks correct on screen. JSON should be encoded as UTF-8 without a BOM. When valid-looking JSON refuses to parse, suspect an invisible character and retype the quotes by hand or paste through a plain-text editor first.

How to catch these mistakes early

You do not have to find these errors by eye. A few habits catch nearly all of them:

1. Validate before you ship. Run your JSON through a validator or a free JSON formatter & validator; it reports the exact line and character of the first problem.
2. Format consistently. Prettifying your JSON makes unbalanced brackets and stray commas visible at a glance. See minify vs prettify JSON for when to use each.
3. Read parser errors literally. Messages like unexpected token usually point right at the problem; our guide to fixing unexpected-token errors decodes the common ones.
4. Enforce structure with a schema. For data that flows between systems, JSON Schema validates not just syntax but shape and types.

Key takeaways

• JSON is strict: double quotes only, no trailing commas, no comments, and lowercase true, false, and null.
• Every key must be a quoted string, and every bracket and brace must be balanced.
• Numbers cannot have leading zeros, plus signs, or hex notation — store identifiers with leading zeros as strings.
• Escape backslashes, quotes, and newlines inside strings, and watch for invisible smart quotes and BOM characters.
• Let a serializer build your JSON, and validate it before sending. Doing both removes almost every error on this list.

Most json validation failures come down to one of these ten patterns. Internalize the rules, lean on tooling, and your JSON will parse cleanly the first time. If you are still deciding whether JSON is even the right format for your project, compare it with the alternatives in JSON vs XML vs YAML.