JSONJSON5JSONCconfiguration

JSON vs JSONC vs JSON5: A Complete Guide

JSON is strict data interchange, JSONC adds comments mainly for config files, and JSON5 allows more JavaScript-like syntax.

ToolGarden tools prioritize browser-local processing, so files and text do not need to be uploaded to a server.

Published July 2, 2026Updated July 20, 20269 min readBy ToolGarden

JSON, JSONC, and JSON5 look similar, but they are not interchangeable. Mixing them is a common cause of parser errors.

{
  // JSONC / JSON5 allow comments in some tools
  name: 'ToolGarden',
  tags: ['json', 'tools'],
}

Core Differences

Format	Standard JSON?	Main trait
JSON	Yes	Strict and widely supported for APIs and data exchange
JSONC	No	Common for config files, allows comments, stays close to JSON
JSON5	No	More JavaScript-like, allows single quotes, trailing commas, unquoted keys, and more

Why Do APIs Usually Require Standard JSON?

APIs, databases, queues, and third-party platforms need data that can be parsed consistently across languages such as JavaScript, Java, Go, Python, and Rust. Standard JSON has fewer rules and fewer ambiguous edge cases.

Comments are not data and have no shared meaning in API payloads.
Trailing commas, single quotes, and unquoted keys are supported inconsistently across parsers.
NaN and Infinity are not standard JSON values and are often rejected by backends.
Config files can optimize for humans; API payloads should optimize for stable machine parsing.

Why Can tsconfig.json Contain Comments?

Many developers first notice comments in tsconfig.json and wonder why a .json file can contain //. TypeScript reads that file with JSONC-like rules, which is not the same as ordinary JSON parsing for API payloads.

File or case	Common format	Can you send it to a normal API?
tsconfig.json	JSONC-style config	Do not assume so
VS Code settings.json	JSONC-style config	Do not assume so
package.json	Standard JSON	Usually yes
API request body	Standard JSON	Should be standard JSON

How to Convert JSONC / JSON5 to Standard JSON

Parse the loose syntax and confirm that a JSONC or JSON5 parser understands it.
Remove comments and trailing commas, and quote unquoted keys.
Convert single-quoted strings to double-quoted JSON strings.
Check for unsupported values such as NaN, Infinity, and undefined.
Validate the final output with a strict JSON validator.

Which One Should You Use?

For API requests and responses, use standard JSON.
For human-maintained config files, JSONC can work when the toolchain supports it.
For JavaScript-like authoring convenience, JSON5 can be useful but is not accepted by ordinary JSON APIs.
Before sending data to a backend, database, or third-party system, convert to standard JSON.

Frequently asked questions

Q.Why doesn't JSON allow single-quoted strings?

The JSON spec (RFC 8259) requires strings to be wrapped in double quotes. This is not arbitrary; it keeps the rules minimal and cross-language parsers consistent. Single quotes are also valid string delimiters in many languages, but each language handles them slightly differently (Python treats both as equivalent; Java and C# only use double quotes; JavaScript accepts both). Restricting JSON to double quotes avoids all that ambiguity. JSON5 allows single quotes because it targets JavaScript developers and prioritizes hand-writing convenience, but any API-bound JSON must use double quotes.

Q.Can I use NaN or Infinity in JSON?

No. Standard JSON only allows finite number literals (0, 1, -3.14, 1e10), not IEEE 754 special values like NaN, Infinity, -Infinity, or undefined. JavaScript's JSON.stringify(NaN) returns null on purpose, to keep output valid. If your data legitimately has NaN or Infinity (scientific computing, ML output), common workarounds are: convert them to null; convert to string sentinels like "NaN" and "Infinity" and handle on the frontend; or replace Infinity with an agreed-upon large value. JSON5 accepts these values, but you must normalize before sending to a standard API.

Q.tsconfig.json allows comments; can I put comments in my project's .json files too?

It depends. tsconfig.json, VS Code's settings.json, and some launch.json files support comments because TypeScript and VS Code read them with a JSONC parser; a special convention, not part of the JSON spec. If your own project's config.json is parsed by JavaScript's JSON.parse, Python's json.loads, or Java's Jackson, comments cause parse errors immediately. To use comments in config, pick a JSONC-aware parser like jsonc-parser, switch to YAML or TOML, or keep comments in a separate README.

Q.Why do trailing commas work in some parsers but not others?

Standard JSON strictly forbids trailing commas: [1, 2, 3,] and {"a":1,} are invalid. JavaScript itself allows trailing commas, so V8, SpiderMonkey, and lenient modes plus JSON5 accept them. Python's json module, Java's Gson, and Go's encoding/json enforce the spec and reject them. That is why pasting a JSON with a trailing comma into a browser console works, while the same string sent to a backend fails. When writing standard JSON, remove all trailing commas or use a formatter to clean them up automatically.

Q.Should I use JSON5 or JSONC?

Depends on the use case. JSONC is conservative; it only adds comments, keeps everything else close to JSON, and fits existing JSON files that need human annotations (configs, sample data). JSON5 is more aggressive, allowing single quotes, trailing commas, unquoted keys, multi-line strings, and hex numbers, feeling closer to a JavaScript object literal. It suits hand-written data files where your own toolchain controls parsing (Babel config, Rollup config). If you only need comments, use JSONC. If double quotes and quoted keys feel too noisy, use JSON5. Either way, always convert to standard JSON before hitting an API.