{ jsonzen }0 bytes uploaded
2026-06-01

How to fix invalid JSON: a complete guide

Every common JSON parse error, what causes it, and how to fix it — with examples and tooling.


title: "How to fix invalid JSON: a complete guide" slug: "how-to-fix-invalid-json" date: "2026-06-01" description: "Every common JSON parse error, what causes it, and how to fix it — with examples and tooling." keywords:

  • fix invalid json
  • json error
  • json parse error
  • invalid json fix
  • how to fix json ogTitle: "How to fix invalid JSON: a complete guide · jsonzen"

You call JSON.parse(), and instead of data you get SyntaxError: Unexpected token } in JSON at position 42. The error tells you where the parser gave up, not why the JSON is broken — which is almost always somewhere upstream of that position. Here are the 7 most common causes of invalid JSON and exactly how to fix each one.

1. Trailing commas

JavaScript has allowed trailing commas in arrays and objects since ES5, so many developers write them reflexively. JSON, however, does not allow them. The spec is unambiguous: a value list ends with the last value, full stop.

// Wrong — trailing comma after "c"
{"items": ["a", "b", "c",]}
// Right
{"items": ["a", "b", "c"]}

This tends to show up when you copy a JavaScript object literal into a JSON file, or when you delete the last item in an array and forget to remove the comma that was after the new last item. Editors with JSON linting (VS Code highlights it in red) catch this immediately, but raw text editors don't.

2. Single quotes

JSON strings — both keys and values — must be wrapped in double quotes. Single quotes are not valid JSON syntax. This is probably the single most common mistake when transcribing a JavaScript object literal into JSON, since JS happily accepts either.

// Wrong — single-quoted key and value
{'name': 'Alice'}
// Right
{"name": "Alice"}

A global find-and-replace from ' to " usually isn't safe here because single quotes might appear inside string values as apostrophes. Fix them structurally — key delimiters and string delimiters only — rather than doing a blind substitution across the whole file.

3. Unquoted keys

JavaScript object literal keys can be bare identifiers: {name: "Alice"} is perfectly valid JS. In JSON every key is a string and must be quoted. Paste JS object syntax into a JSON file and the parser will reject it.

// Wrong — unquoted key
{name: "Alice", age: 30}
// Right — all keys double-quoted
{"name": "Alice", "age": 30}

When you're dealing with a large JS object you want to serialize, the right move is to let the JS runtime do it: JSON.stringify(obj) produces valid JSON. Don't hand-convert large object literals.

4. JavaScript-style comments

// line comments and /* block comments */ are not part of the JSON specification. If you write them in a .json file, every conformant JSON parser will throw.

// Wrong — comments are not valid JSON
{
  // user record
  "id": 1,
  "name": "Alice" /* primary account */
}
// Right — remove comments entirely
{
  "id": 1,
  "name": "Alice"
}

If you need annotated config files, two paths forward: use a format that genuinely supports comments — JSON5 (.json5) or JSONC (.jsonc, used by VS Code and TypeScript) both allow // and /* */ comments — or move comments into a separate documentation layer and keep your data files clean JSON. Don't silently strip comments with a pre-processor and pretend the file is still JSON; that just hides the problem.

5. Unescaped special characters in strings

JSON strings must be valid Unicode with specific characters escaped. The characters that most often cause silent breakage are:

  • Literal newlines and tabs — a raw newline inside a string value terminates the string and creates a parse error. Use \n for newlines, \t for tabs.
  • Unescaped double quotes — a " inside a double-quoted string must be \".
  • Backslashes — a literal \ must be \\.
// Wrong — literal newline inside the string
{
  "message": "Hello
world"
}
// Right — escaped newline
{
  "message": "Hello\nworld"
}

This typically surfaces when JSON is generated by hand or by a template that doesn't run values through a proper serializer. The fix is to always build JSON programmatically using JSON.stringify() or an equivalent library in your language, rather than constructing it by string concatenation.

6. Mismatched braces or brackets

A missing }, extra ], or swapped } for ] somewhere in a deeply nested structure will cause a parse error at the end of the document (or at the first point where the mismatch becomes unresolvable), not at the line where the mistake actually lives. The parser reports where it got confused, not where the bug is.

// Wrong — missing closing bracket on the array
{
  "users": [
    {"id": 1},
    {"id": 2}
}
// Right
{
  "users": [
    {"id": 1},
    {"id": 2}
  ]
}

For anything longer than 10–15 lines, don't try to find mismatches by reading. Paste the JSON into the JSON Validator — it reports the exact line and column of the structural error, which is almost always faster than scanning manually. Editors with bracket-matching (the % command in Vim, bracket highlighting in VS Code) also help here.

7. Encoding issues: BOM and smart quotes

Two encoding problems that look like JSON errors but are actually text encoding problems:

Byte-order mark (BOM). When a Windows application saves a UTF-8 file, it sometimes prepends a 3-byte sequence (EF BB BF in hex) called a BOM. Most JSON parsers don't strip it, so they see the very first character as the BOM bytes rather than {, and the parse fails immediately. Open the file in a hex editor or run file -i yourfile.json on Linux/Mac — if you see UTF-8 with BOM, strip it. Most code editors have a "save without BOM" option; on the command line sed -i '1s/^\xEF\xBB\xBF//' file.json removes it.

Smart quotes / curly quotes. Text pasted from Word, Google Docs, Notion, Slack, or any rich-text editor often carries typographic " (U+201C / U+201D) instead of the straight " (U+0022) that JSON requires. They look identical in most fonts. The tell is a parse error at position 0 or at the first string in the document, and a hex view that shows E2 80 9C where you expect 22.

// Wrong — curly/smart quotes (U+201C / U+201D)
{
  “name”: “Alice”
}
// Right — straight ASCII double quotes (U+0022)
{
  "name": "Alice"
}

Fix by opening the file in a plain-text editor, doing a find-and-replace for "" and "". A smarter approach is to run it through the JSON Formatter, which normalises quote characters automatically.

When to use a repair tool

For a single broken API response, fixing by hand takes 30 seconds. For recurring situations — LLM-generated JSON that occasionally hallucinates trailing commas, large scraping pipelines that produce malformed output, or a dataset someone exported from Excel — fixing by hand does not scale.

The JSON Repair tool handles all seven categories above: it strips trailing commas, normalises quote characters, adds missing brackets, escapes bare control characters, and removes comments — entirely in your browser with no server upload. For one-off fixes it's faster than hunting through the spec; for automated pipelines it gives you a reliable pre-processing step before you hand data to your application.

A rough guide:

  • Single response, small file — fix manually using the error message and this guide.
  • Recurring output from an LLM or scraper — run it through a repair tool as a normalisation step before parsing.
  • Large config or dataset file — validate first with the JSON Validator to find every error in one pass, then fix systematically or use repair for the mechanical fixes.

The goal is always to get to valid, spec-compliant JSON as fast as possible. Repair tools are a means to that end, not a substitute for understanding what went wrong.

TL;DR

  • Trailing commas — remove the comma after the last item in any array or object.
  • Single quotes — replace all string/key delimiters with double quotes.
  • Unquoted keys — every key must be a double-quoted string.
  • Comments — JSON has no comment syntax; delete them or switch to JSON5/JSONC if you need annotations.
  • Unescaped special characters — use \n, \t, \", \\ inside strings; never embed raw newlines or unescaped quotes.
  • Mismatched braces/brackets — use a validator to find the exact position; don't scan by eye.
  • BOM / smart quotes — strip the BOM from UTF-8 files; replace curly quotes with straight ASCII " before parsing.