← Back to the JSON tool

JSONC to JSON

Last updated: 24 October 2026

Your file works in the editor and fails in the parser, because it is not JSON — it is JSONC, and JSON has no comment syntax. Paste it here to see exactly which comments and trailing commas have to go, and get the strict equivalent.

Why a file that opens fine refuses to parse

Strict JSON has no comment syntax. The grammar defines strings, numbers, the literals true, false and null, and the six structural characters — and that is the whole list. A // is not in it, so the parser stops there and reports an error, which is why a tsconfig.json that your editor happily displays can fail the moment JSON.parse sees it.

Nothing is wrong with the file, and nothing is wrong with the parser. Two different languages are involved: the editor reads JSONC, and your code reads JSON. VS Code reads tsconfig.json, .vscode/settings.json, devcontainer.json and similar files as JSONC, so it strips the comments as it loads them and never shows you the difference.

What JSONC actually allows

Two relaxations and no more:

• Comments — both // line comments and /* block comments */. They are allowed wherever whitespace is allowed, including after the last property, between a key and its colon, and inside a container that has no properties at all.
• Trailing commas — a comma after the final element of an object or an array, with any amount of whitespace or a newline before the closing bracket.

Everything else is unchanged from JSON: strings and property names use double quotes, numbers keep the JSON grammar, and there is no undefined, no NaN and no leading plus sign. That is the difference from JSON5, which is a much larger superset and is treated separately below.

The trap this tool has to avoid

Stripping comments looks like a one-line regular expression, and that version is unsafe on real payloads. A double slash appears inside perfectly ordinary string values — every https URL has one, and "https://example.com//path" even has two. Run //[^\n]* over it and the rest of the line is deleted, turning a valid document into an unterminated string, or worse, into a shorter one that still parses with a value quietly truncated.

So the conversion here walks the text character by character and tracks whether it is inside a string, honouring backslash escapes. A comment marker only counts when it appears outside a string, which is the only place JSONC allows it. Whitespace inside a string is never touched, and if the document already parses as strict JSON the tool says so and changes nothing.

JSONC and JSON5 are not the same file

JSON5 is where people usually land after this problem, and it is a much bigger dialect: single-quoted strings, unquoted keys, hexadecimal numbers, + signs, leading and trailing decimal points, Infinity, NaN, multi-line strings and additional escapes. Converting JSON5 by deletion is not safe, because several of those forms carry values that JSON cannot represent at all — NaN has no JSON counterpart, and Infinity needs a decision, not a rewrite.

This page therefore refuses them. If the text is not JSON plus comments and trailing commas, the conversion fails and says which category the remaining problem belongs to, instead of inventing a value.

Reading it as JSON fails where the comment is

There is nothing subtle about the failure, which is what makes it easy to confirm. Read a commented tsconfig.json with the strict reader and it stops at the first comment:

node -e "JSON.parse(require('fs').readFileSync('tsconfig.json','utf8'))"

SyntaxError: Expected property name or '}' in JSON at position 4
             (line 2 column 3)

That position is the comment, not the data. The value on line 3 parses perfectly well; the parser never reaches it. Running the same command against a comment-free file prints the object and exits silently, which is the control that tells the two cases apart.

The tools that own these formats already handle it, and that is why the file got written this way in the first place — tsc reads tsconfig.json through its own JSONC parser, and VS Code reads its configuration files the same way, so neither of them ever reports a problem. Only code that later opens the file as data hits the wall.

The durable fix is to keep the comment-carrying file as the source of truth for humans and emit a strict copy for machines, rather than teaching a service to read a relaxed dialect. Two systems reading one file with two different parsers is how a trailing comma becomes a production incident.

Where this sits next to the other tools

If the file is strictly valid JSON, the validator gives you the line and column of any error and names the usual cause. If it is not valid and you want to know why in detail, the syntax cheat sheet lists what the grammar allows. Once it is strict, the formatter pretty-prints it and the minifier compresses it for transport.

Frequently Asked Questions