What's the difference between JSON, JSONC, and JSON5?

Strict JSON (RFC 8259) doesn't allow comments, trailing commas, single-quoted strings, or unquoted keys. JSONC (JSON with Comments) adds // and /* */ comments and trailing commas — used in tsconfig.json and VS Code settings. JSON5 is broader: also adds single-quoted strings, unquoted keys, hex literals, NaN/Infinity.

Will this parse a tsconfig.json?

Yes — tsconfig.json uses JSONC, and the parser handles all the JSONC features (comments, trailing commas) it uses in practice. Paste your tsconfig.json or .vscode/settings.json and you'll get strict JSON back.

Will the output preserve the comments?

No — strict JSON has no comment syntax, so comments are stripped on conversion. To preserve documentation, keep the JSONC original alongside the strict output, or move comments into a separate _doc field with the comment text as the value.

How are trailing commas handled?

Silently accepted and dropped. {"a": 1, } becomes {"a": 1}. [1, 2, 3,] becomes [1, 2, 3]. Both at the end of a value list and after the last element of a single-element collection.

May 2, 20268 min read

JSON5 Parser Online: Comments + Trailing Commas Guide

Q: Is the input sent to a server?

No. The parser runs entirely in your browser. Configs containing tokens, internal hostnames, or secrets stay on your device.

Looking for a reliable JSON5 parser online? Here's the practical workflow. You hand a colleague a tsconfig.json. They feed it into a tool that calls strict JSON.parse and watch it fail spectacularly on the comments. The file is correct — the parser is too strict. JSON5 and JSONC exist precisely for this case.

In this guide you'll learn how to parse JSON5 and JSONC using PDFFlare's JSON5 / JSONC parser — the differences between strict JSON, JSONC, and JSON5; what each variant adds; how to convert any of them to strict JSON for downstream tools; and the gotchas that bite even battle-hardened parsers.

How to Use a JSON5 Parser Online (Step-by-Step)

The interactive tool above does most of the work. The rest of this guide covers patterns, edge cases, and production tips you'll want to keep in mind.

Strict JSON vs JSONC vs JSON5

Strict JSON (RFC 8259): the lowest common denominator. No comments, no trailing commas, no single-quoted strings, no unquoted keys.
JSONC ("JSON with Comments"): a Microsoft variant used in tsconfig.json and VS Code settings. Adds // line and /* block */ comments and trailing commas. Otherwise strict.
JSON5: a broader spec adding single-quoted strings, unquoted keys, hex literals (0xFF), NaN/Infinity, and other JS-friendly affordances.

How to Parse JSON5 / JSONC (Step by Step)

Open PDFFlare's JSON5 / JSONC parser.
Paste your JSONC or JSON5 input. tsconfig.json, settings.json, or any config file with comments and trailing commas.
Click Parse to JSON. Comments are stripped, trailing commas dropped, and the output is strict JSON any parser will accept.
Copy the strict JSON.Drop into systems that don't accept JSONC (databases, JSON-only config loaders, most APIs).

Real Use Cases

tsconfig.json review

Inspect a tsconfig in a tool that only speaks strict JSON. Paste, parse, get clean output you can diff or hash.

Migrating from JSONC to JSON

Moving config out of JSONC into a system that only accepts strict JSON (databases, some CI tools). Convert all the comment-bearing files in one go.

Comparing two .vscode/settings.json files

JSON Diff expects strict JSON. Parse JSONC first, then diff. Same trick applies for any tool that requires strict input.

Bridging an upstream that emits JSON5

Some config exports include JSON5 — convert to strict JSON for downstream consumers that don't support the dialect.

Common Mistakes (and How to Avoid Them)

Expecting comments to round-trip.Strict JSON has no comment syntax — they're stripped on conversion. To preserve documentation, keep the JSONC original alongside.
Confusing JSON5 with YAML. Both are human-friendly, but JSON5 is a superset of JSON; YAML is a different format. See JSON to YAML for cross-format work.
Trying to round-trip arbitrary JS expressions. JSON5 isn't JavaScript — it's a permissive JSON superset. Functions, references, and expressions aren't supported.
Assuming every JSON5 spec edge case works. The tool covers what shows up in real config files (comments, trailing commas, single quotes, unquoted keys, hex, NaN). For edge cases of the official spec, the npm json5 package is more thorough.

Privacy: Your Input Stays Local

The parser runs entirely in your browser. Configs containing tokens, internal hostnames, or secrets stay on your device.

Related Workflows in the JSON Suite

Adjacent tools you might find useful while working on the same JSON document: the JSON Formatter and JSON Schema validator both pair well with the conversion above. The first handles a different output format that consumers of your data may prefer; the second covers the validation side of the same workflow.

Related Tools

JSON Formatter — format the strict-JSON output to a project-standard indent.
JSON Diff — compare two configs after parsing each.
JSON Sort — canonicalise the output for stable hashes.
JSON Viewer — browse the parsed tree.

Choosing Between JSON, JSONC, and JSON5

The choice between strict JSON, JSONC, and JSON5 deserves deliberate thought rather than habit. Each format has tradeoffs that suit different use cases, and picking the right one for the right context avoids self-inflicted pain later. Strict JSON wins for machine-to-machine communication. JSONC wins for hand-edited config files where comments add genuine value. JSON5 wins for cases where ergonomics matter more than ecosystem support, which is rarely true in practice.

For machine-to-machine communication, strict JSON is almost always the right choice. Every parser in every language understands it. Tooling for validation, schema generation, and inspection assumes strict syntax. Adding comments or trailing commas to a wire format provides no value and creates compatibility surface area. The only reason to deviate is if you control both ends of the conversation and have a specific need that strict JSON cannot meet — which is essentially never.

For hand-edited config files, JSONC is the modern consensus. The TypeScript ecosystem standardized on it, VS Code adopted it for settings, and a growing number of developer tools support it. Comments in config files genuinely help: they explain why a particular setting was chosen, document expected behavior, and serve as inline warnings against changing things blindly. A strict JSON config file has no place to put this context, and external documentation always drifts out of sync with the file itself.

JSON5 sits in an awkward middle ground. It adds features beyond comments — single-quoted strings, unquoted keys, hex numbers — that go beyond what configuration usually needs. The extra features make it look more like JavaScript, which is convenient for some use cases but disqualifying for others. Tooling support is narrower than JSONC. Use JSON5 when your specific use case demands its features; otherwise JSONC gets you most of the benefit with broader ecosystem support. The principle is: pick the strictest format that meets your real needs, because every relaxation is a potential source of incompatibility.

Production Patterns for Parsing JSON5 / JSONC

A few patterns that make production usage smoother:

Convert Once, Cache the Result

If your build pipeline reads tsconfig.jsonon every change, parse it once and cache the strict-JSON form. JSONC parsing is fast but unnecessary work. Most build tools already do this; if you're writing your own, remember to cache.

Preserve Comments When Round-Tripping

The standard parsers strip comments — they have no representation in JavaScript's native types. If you need to round-trip (read, modify, write back), use a comment-aware editor like jsonc-parser from VS Code, which preserves comments and trailing commas through edits.

Schema-Validate the Parsed Output

A loose JSON5 file is easy to typo. After parsing to strict JSON, validate against a JSON Schema so config errors fail loudly at startup, not silently at runtime.

When to Use a Different Format

JSON5 / JSONC is great for human-edited config but not for everything:

For machine-only configs, stick with strict JSON. No comments, fewer parser quirks.
For DevOps configs (Kubernetes, GitHub Actions), YAML is the convention. Use JSON to YAML to convert.
For Rust/Python configs, TOML is more idiomatic — see JSON to TOML.

Common Mistakes to Avoid

Pasting JSON5 into a strict-JSON parser. JSON.parsedoes NOT accept comments or trailing commas. The error messages are unhelpful (“Unexpected token /”). Always parse with a JSON5/JSONC-aware parser when input might have those.
Single quotes inside string literals. JSON5 allows single-quoted strings, but if your string itself contains a single quote, escape it. Otherwise the parser terminates the string early and reports a confusing error on the next character.
Trusting the source. JSON5 files in a repo are fine. JSON5 from user input — sanitize first. Some JSON5 parsers have had RCE-style issues in the past (rare, but worth being aware of).
Mixing JSON5 with strict JSON tooling. A JSON Schema validator may not accept JSON5 syntax. Convert to strict JSON first, then validate.
Forgetting hex / NaN / Infinity. JSON5 allows 0xff, NaN, Infinity — strict JSON does not. If you convert JSON5 → strict JSON, those values lose precision (NaN becomes null, hex becomes decimal).

Real-World Use Cases

tsconfig.json-style build configs. TypeScript's tsconfig allows comments by design. Most JS build tools do.
VS Code extension settings. .vscode/settings.json is JSONC. Parse with a JSONC-aware parser when reading from extensions.
Application config files. Allow your users to add comments documenting their non-default choices — invaluable for ops handover.
Migration scripts. Reading legacy configs that were technically JSON but had comments people slipped in over the years. JSON5 parses what strict parsers choke on.

Polishing the Generator's Output

The decision to use JSON5 or JSONC over strict JSON is fundamentally about the audience for the file. Whatever your specific use case, treat the generated output as a draft that deserves a careful read-through. Generators are excellent at producing the mechanical structure of an artifact and not at the editorial decisions that make the difference between something a colleague will tolerate and something a colleague will appreciate. Read every section of the output the way you would read a piece of writing you were proofreading for a friend. Look for inconsistent naming, missed opportunities to consolidate similar items, and places where the structure is mechanically correct but conceptually awkward. The five minutes spent on this review are the difference between an artifact that pays back over months and one that needs a second pass before it can be used. The generator handles the heavy lifting; you handle the polish that turns a draft into a deliverable. This division of labor is what makes generated code worthwhile in the first place. Without that final pass of human editorial judgment, the generator's output is merely fast rather than valuable, and the value matters more than the speed in nearly every real production setting.

Wrapping Up

JSONC and JSON5 exist because config files benefit from comments. PDFFlare's JSON5 / JSONC parser bridges the gap between the friendly format you write and the strict format other tools demand.