You write a config file, copy a payload from documentation, or paste a response from an API — and suddenly your application refuses to start. The error message says something like SyntaxError: Unexpected token but points to a line that looks perfectly fine. JSON is deceptively simple on the surface, yet its strict syntax catches developers off guard every day.

The browser's built-in JSON.parse() is notoriously unhelpful when something goes wrong. You get a terse error and a character position that often points to the consequence of the mistake rather than the cause. Knowing the five most common JSON errors — and what they actually look like — means you can fix them in seconds instead of spending half an hour staring at a diff.

Error 1: Trailing Commas

This is the single most frequent JSON mistake, and it almost always comes from developers used to writing JavaScript, Python, or Rust — all of which allow (or even encourage) trailing commas in collections.

What it looks like

{
  "name": "Alice",
  "age": 30,
  "roles": [
    "admin",
    "editor",
  ],
}

The comma after "editor" and the comma after the roles array both violate the JSON specification. RFC 8259, which defines JSON, does not permit trailing commas anywhere — not in objects, not in arrays.

Why it fails

JavaScript objects accept trailing commas as of ES5, so developers naturally write them out of habit. But JSON is not JavaScript. It is a data interchange format with a much stricter grammar. The JSON.parse() function in every browser and runtime rejects trailing commas immediately.

The fix

{
  "name": "Alice",
  "age": 30,
  "roles": [
    "admin",
    "editor"
  ]
}

Remove the comma after the last item in every array and the last property in every object. If you work with JSON frequently, configure your editor to flag trailing commas in .json files — most linters have a dedicated rule for this.

Error 2: Single Quotes Instead of Double Quotes

JSON requires double quotes around all strings — both keys and values. Single quotes are completely invalid, even though they work fine in JavaScript object literals.

What it looks like

{
  'host': 'localhost',
  'port': 5432,
  'database': 'myapp'
}

Why it fails

The JSON grammar defines a string as a sequence of characters enclosed in double quotation marks ("). Single-quoted strings are simply undefined in the spec — the parser encounters a ' character where it expects a " or a } and immediately throws.

This mistake is extremely common when copying snippets from JavaScript tutorials, Python dictionaries, or shell scripts where single-quoted strings are idiomatic.

The fix

{
  "host": "localhost",
  "port": 5432,
  "database": "myapp"
}

Replace every single quote used as a string delimiter with a double quote. Note that port here is a number — numbers, booleans (true, false), and null must not be quoted at all.

Error 3: Unquoted Keys

In JavaScript, object keys can be unquoted identifiers: { host: "localhost" }. In JSON, every key must be a quoted string, without exception.

What it looks like

{
  name: "Alice",
  age: 30,
  active: true
}

Why it fails

The JSON specification defines an object as a set of name/value pairs where the name is always a string. A bare identifier like name is not a string. The parser expects either a double-quote character or a closing brace when reading a new key, and an unquoted letter immediately causes a syntax error.

This mistake is especially common when developers hand-write configuration files and unconsciously switch between JSON and JavaScript object syntax, or when they copy code examples from README files that use JavaScript notation for brevity.

The fix

{
  "name": "Alice",
  "age": 30,
  "active": true
}

Wrap every key in double quotes. Values that are strings also need double quotes; numbers, booleans, and null do not.

Error 4: Comments in JSON

JSON does not support comments. Not line comments (//), not block comments (/* */), not hash comments (#). If you include any of them, the parser will fail.

What it looks like

{
  // Database connection settings
  "host": "localhost",
  "port": 5432, /* default PostgreSQL port */
  "database": "myapp" # production DB
}

Why it fails

Douglas Crockford, who formalized JSON, intentionally left comments out of the specification. His reasoning was that comments in configuration files tend to accumulate parsing directives (e.g. // eslint-disable), which makes the format non-interoperable between different tools. The decision is controversial but final — JSON parsers are not required to handle comments, and most strict parsers reject them outright.

The confusion is amplified by the fact that several popular tools accept a superset of JSON that allows comments — notably VS Code's tsconfig.json and jsconfig.json, which use JSONC (JSON with Comments). These files look like JSON but are not valid JSON and will fail with standard parsers.

The fix

{
  "host": "localhost",
  "port": 5432,
  "database": "myapp"
}

Remove all comments. If you need annotated configuration, consider TOML, YAML, or JSONC — but be explicit about which format your parser expects. For pure JSON files, move documentation into a separate README or use a "$comment" key, which some JSON Schema validators recognise as a conventional comment field.

Error 5: Wrong Encoding, BOM Characters, and Invisible Unicode

This is the most subtle error on the list because it is completely invisible. Your JSON looks valid. Every quote is in place. There are no trailing commas. But the parser still refuses to accept it.

What it looks like

A JSON file saved with UTF-8 BOM (Byte Order Mark) by a Windows tool will have three extra bytes — 0xEF 0xBB 0xBF — prepended to the file before the opening {. These bytes decode to the Unicode character U+FEFF and are completely invisible in most text editors.

{
  "status": "ok"
}

The invisible before the opening brace is U+FEFF. Most terminals and editors will not render it, but every JSON parser will either fail outright or produce subtly broken output.

Why it fails

RFC 8259 explicitly states that JSON text must not begin with a BOM. The spec also requires UTF-8 encoding without a BOM for JSON transmitted over the network. Many parsers are lenient about this in practice, but strict parsers — including Node.js's JSON.parse() when the string contains the actual U+FEFF character — will throw a syntax error pointing at position 0, which is baffling if you cannot see the character.

Related problems include mixed encodings (a file that is mostly UTF-8 but contains a few Latin-1 bytes), zero-width spaces (U+200B) accidentally pasted into string values, and non-breaking spaces (U+00A0) in place of regular spaces in keys. All of these are invisible in rendered text but real bytes in the file.

The fix

In the terminal, you can strip a UTF-8 BOM from a file with:

sed -i '1s/^\xEF\xBB\xBF//' file.json

In Node.js, strip the BOM before parsing:

const raw = fs.readFileSync('file.json', 'utf8');
const text = raw.charCodeAt(0) === 0xFEFF ? raw.slice(1) : raw;
const data = JSON.parse(text);

To detect zero-width and invisible characters inside string values, inspect code points directly:

const suspicious = Array.from(str).filter(ch => {
    const cp = ch.codePointAt(0);
    return cp === 0xFEFF || cp === 0x200B || cp === 0x00A0
        || cp === 0x200C || cp === 0x200D;
});
console.log(suspicious.map(ch => 'U+' + ch.codePointAt(0).toString(16).toUpperCase()));

The root cause is almost always tooling: Windows Notepad, Excel CSV exports, and some IDEs default to "UTF-8 with BOM". Switching the save encoding to "UTF-8 without BOM" in your editor prevents the issue entirely.

Why JSON.parse() Error Messages Are So Unhelpful

All five errors above will cause JSON.parse() to throw a SyntaxError, but the messages vary wildly between environments and rarely tell you the actual cause:

  • Chrome: SyntaxError: Unexpected token ',' JSON at position 42
  • Firefox: SyntaxError: JSON.parse: unexpected character at line 4 column 5
  • Node.js: SyntaxError: Unexpected token } in JSON at position 87

The reported position points to where the parser gave up, not necessarily where the mistake is. A trailing comma on line 3 might be reported as an error on line 4 because the parser only realises something is wrong when it sees the next token. A BOM character at position 0 causes an error that says "unexpected token" for the very first character of what you thought was perfectly valid JSON.

The most effective strategy is to validate your JSON with a tool that gives you proper context — highlighting the exact region with the problem rather than just a byte offset. The JSON Formatter & Validator parses your JSON, highlights errors with a precise description, and pretty-prints valid JSON so structural mistakes become visually obvious at a glance.

Quick Reference: JSON Rules to Remember

  • All keys must be strings in double quotes.
  • All string values must use double quotes — never single quotes.
  • No trailing commas after the last item in arrays or objects.
  • No comments of any kind (//, /* */, #).
  • Numbers, true, false, and null are not quoted.
  • Files must be UTF-8 without BOM.
  • No invisible or control characters outside of string values.

JSON's strictness is a feature, not a bug — it makes the format trivially parseable by any language with zero ambiguity. The cost is that there is no forgiveness for mistakes that JavaScript happily ignores. Keep these five error patterns in mind and you will spend far less time hunting for the stray comma that broke your deployment pipeline.