JSON5 vs JSON: Why LLMs Produce JSON5-Flavored Output (and How to Fix It)

JSON5 reached 167 million npm downloads per week in 2026. That's not a niche format — that's a format embedded in the JavaScript ecosystem at a scale that rivals core utilities.

But there's a problem: your JSON.parse() calls don't speak JSON5. And neither does Python's json.loads(), Go's encoding/json, or virtually any standard library in any language.

Worse: LLMs produce JSON5-flavored output. Not because they're wrong — they were trained on billions of documents that include JSON5-like syntax — but because without strict schema enforcement, models drift toward the slightly-more-relaxed format they've seen more of.

The result is JSON that looks valid, passes a quick glance test, and then breaks silently in production.

This guide explains the technical difference between JSON5 and JSON, why LLMs produce hybrid output, and how to catch and repair it.

---

JSON5 vs JSON: The Key Differences

JSON5 is a superset of JSON, introduced in 2012 by Aseem Moudgal, designed to address some of JSON's limitations as a human-authored format. It adds features that appear frequently in JavaScript object literals and configuration files.

Here's what JSON5 permits that standard JSON does not:

1. Single-Quoted Strings

JSON5 (valid):

{
  'name': 'Alice',
  'status': 'active'
}

Standard JSON (required):

{
  "name": "Alice",
  "status": "active"
}

JSON.parse("{'name': 'Alice'}") throws a SyntaxError. Always.

---

2. Trailing Commas

JSON5 (valid):

{
  "items": [
    "first",
    "second",
    "third",
  ],
}

Standard JSON: The trailing comma after "third" and after the closing ] are both syntax errors.

This is the most common LLM failure pattern. Models generate lists and objects, add a trailing comma after the last element, and standard parsers reject it.

---

3. Unquoted Object Keys

JSON5 (valid):

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

Standard JSON: Keys must be double-quoted strings.

---

4. Comments

JSON5 (valid):

{
  // user configuration
  "theme": "dark",
  "fontSize": 14 / px /
}

Standard JSON: No comments. Both // and / / are parse errors.

---

5. Multi-Line Strings

JSON5 (valid):

{
  "sql": "SELECT *
    FROM users
    WHERE active = true"
}

Standard JSON: Literal newlines inside string values are illegal. Must be escaped as \n.

---

6. Hexadecimal Numbers

JSON5 (valid):

{
  "flags": 0xFF,
  "mask": 0b1010
}

Standard JSON: Only decimal numbers. 0xFF is a parse error.

---

7. Plus Sign and Leading/Trailing Decimal Points

JSON5 (valid):

{
  "multiplier": +1.5,
  "fraction": .5,
  "whole": 1.
}

Standard JSON: No leading +, no leading ., no trailing ..

---

Quick Reference: JSON5 vs JSON

---

Why LLMs Produce JSON5-Flavored Output

This is the part that catches most developers off guard.

LLMs are trained on enormous corpora of text from the web, GitHub, npm packages, and technical documentation. A significant fraction of that data is JavaScript source code — which uses object literals that look like JSON but aren't:

// This is valid JavaScript, not JSON
const config = {
  env: 'production',
  debug: false,
  ports: [8080, 8443,],  // trailing comma
}

Models see this syntax billions of times. When they generate "JSON" output, they've absorbed both strict JSON and the looser JavaScript object literal syntax. Without strict schema enforcement (OpenAI's response_format: {type: "json_schema"}, Anthropic's output_config, Gemini's response_schema), models sometimes drift toward JavaScript-style output.

The six most common LLM JSON5 failure patterns:

1. Trailing commas — model ends a list or object with , ] or , } instead of ] or }
2. Single quotes — model uses 'value' instead of "value", especially for short strings
3. Unquoted keys — model writes {name: "Alice"} instead of {"name": "Alice"}
4. Comments in output — model adds // explanation inline with JSON, especially in "thinking aloud" responses
5. Python literals — True, False, None instead of true, false, null (a Python dict spillover, not JSON5, but similar failure mode)
6. Multi-line strings — model breaks a long string across lines without escaping the newline

These failures are especially common when:

• Using JSON mode without a schema (still 8–15% failure rate across major providers)
• Running open-source models (Llama, Mistral, Gemma) without constrained decoding
• Chaining agents where intermediate outputs aren't schema-validated
• Using no-code tools (Zapier, Make) where the LLM step doesn't expose schema enforcement

---

The Silent Failure Problem

The insidious part of JSON5-flavored LLM output is that it's visually valid. A human reading the output says "that's JSON" — because it is, almost.

{"result": "success", "items": ["a", "b", "c",]}

This looks correct. The trailing comma after "c" is easy to miss. But:

import json
json.loads('{"result": "success", "items": ["a", "b", "c",]}')
json.decoder.JSONDecodeError: Expecting value: line 1 column 46 (char 45)

In production, this surfaces as:

• json.decoder.JSONDecodeError in Python
• JSON.parse: unexpected character in JavaScript
• invalid character ',' looking for beginning of value in Go
• unexpected token ',' in JSON at position 45 in Node.js

The error message often points to the character after the problem (the ] after the trailing comma), which makes it harder to diagnose without knowing to look for JSON5 patterns.

---

How to Detect JSON5 in LLM Output

Option 1: Try JSON5 parsing first

const JSON5 = require('json5');

function parseFlexible(input) {
  try {
    return JSON.parse(input);         // strict first
  } catch {
    return JSON5.parse(input);         // JSON5 fallback
  }
}

Caution: This approach normalizes the problem rather than fixing it. If your downstream system expects strict JSON (an API, a database, another service), you need to convert JSON5 output to JSON before forwarding.

Option 2: Repair to standard JSON (recommended)

from json_repair import repair_json
import json

def parse_llm_output(raw: str) -> dict:
    """Repair JSON5-flavored LLM output to standard JSON."""
    repaired = repair_json(raw)
    return json.loads(repaired)

The [json-repair](https://github.com/mangiucugna/json_repair) library handles all the JSON5 failure patterns: trailing commas, single quotes, unquoted keys, Python literals, and truncated output. The repaired string is strict JSON that any standard library can parse.

Option 3: Browser-based repair

Paste your LLM output into AI JSONMedic. It identifies and fixes JSON5 patterns along with other LLM failure modes, and shows you what was changed — useful for debugging which pattern your pipeline is hitting.

---

Converting JSON5 to Standard JSON

If you have existing JSON5 files (from configuration tools, CLI outputs, or legacy code) that need to be converted to strict JSON:

Node.js:

const JSON5 = require('json5');

const json5String = `{
  // config
  server: 'localhost',
  port: 3000,
  debug: true,
}`;

const obj = JSON5.parse(json5String);
const strictJson = JSON.stringify(obj, null, 2);
console.log(strictJson);
// {"server": "localhost", "port": 3000, "debug": true}

Python:

import json5  # pip install json5
import json

json5_string = "{'key': 'value', 'items': [1, 2, 3,]}"
obj = json5.loads(json5_string)
strict_json = json.dumps(obj, indent=2)
print(strict_json)
{"key": "value", "items": [1, 2, 3]}

Note: converting JSON5 to JSON loses comments. If comments carry semantic meaning in your config files, consider keeping the source as JSON5 and only converting at the API/service boundary.

---

Should You Use JSON5 in Your LLM Pipeline?

The short answer: no, don't build your pipeline on JSON5 output.

The longer answer:

JSON5 as the target format breaks downstream compatibility. Every language's standard library speaks JSON. Adding JSON5 as your data exchange format means every consumer needs to add a JSON5 parser — a dependency with much lower adoption than standard JSON libraries. Native structured output is the correct solution for production. In 2026:

• OpenAI's response_format: {type: "json_schema"} with strict: true enforces standard JSON
• Anthropic's output_config with schema enforces standard JSON
• Google Gemini's response_schema enforces standard JSON

Use native structured output. Validate with Pydantic (Python) or Zod (TypeScript). The 8–15% failure rate of JSON mode without schema enforcement drops to under 0.1% with strict schema enforcement.

Use json-repair as the fallback, not JSON5 parsing. If you can't use native structured output (older API, model without schema support, no-code tool), repair the output to standard JSON rather than accepting JSON5:

from json_repair import repair_json
import json

raw = llm_client.complete(prompt)  # may return JSON5-like output
fixed = json.loads(repair_json(raw))  # always returns standard JSON

JSON5 parsing as a fallback normalizes the failure. Repair to standard JSON catches it and converts it.

---

JSON5 vs YAML vs TOON: The Format Landscape in 2026

For completeness, here's where JSON5 fits in the broader structured data landscape for LLM pipelines:

YAML produces fewer tokens than JSON (no quotes around keys, cleaner multiline), and some LLM research shows slightly better reliability on YAML output than JSON when schema enforcement isn't available. But YAML's reliance on indentation creates its own failure modes.

TOON (Token-Oriented Object Notation) is a 2026 research format showing 39.6% token reduction vs JSON in benchmarks. It's not production-ready yet — no mainstream parser, no repair tooling. Watch arxiv:2603.03306 if you're interested.

For production in 2026: use JSON with native structured output + schema validation. JSON5 is a config-file format, not a data exchange format for LLM pipelines.

---

Frequently Asked Questions

Is JSON5 valid JSON?

No. JSON5 is a superset of JSON — all valid JSON is valid JSON5, but not all valid JSON5 is valid JSON. The extra features (trailing commas, single quotes, comments, unquoted keys) are not allowed by the JSON specification (ECMA-404 / RFC 8259).

Why do LLMs produce JSON5-flavored output?

LLMs are trained on web corpora that include vast amounts of JavaScript source code, which uses object literals that look like JSON but permit trailing commas, unquoted keys, and other JSON5 features. Without strict schema enforcement, models sometimes reproduce these patterns in their output.

Can I use JSON5 with standard JSON parsers?

No. JSON.parse() in JavaScript, json.loads() in Python, and equivalent standard library parsers in every other language will throw an error on JSON5 input. You need either a dedicated JSON5 parser (json5 npm package, json5 Python package) or a repair tool to convert JSON5 to standard JSON first.

What's the best way to handle JSON5 output from an LLM?

The recommended approach: use the json-repair library to convert the output to standard JSON, then parse with your standard library. For browser-based repair, use AI JSONMedic. For production pipelines, switch to native structured output with schema enforcement to eliminate the problem at the source.

Is JSON5 used in production?

JSON5 is widely used for configuration files — it's the basis of tsconfig.json (which uses JSON5 syntax), VS Code settings files, and many .eslintrc-style configs. It's not widely used as a data exchange format between services, because standard library support is limited.

How do I tell if my LLM is producing JSON5 vs standard JSON?

Try JSON.parse() or json.loads(). If it throws, check for: trailing commas, single-quoted strings, unquoted keys, or inline comments. Those four patterns cover the vast majority of JSON5 output from LLMs.