Can JSON have comments? JSON, JSONC and JSON5

Why the JSON standard has no comments, what people do instead, and how JSONC and JSON5 differ.

Updated 2026-11-04 · 6 minute read

No. Standard JSON has no comments. A // or a /* */ in a .json file makes it invalid, and a strict parser refuses it.

That is the short answer. The longer answer is more useful, because almost every developer meets a .json file that holds comments anyway.

Why the standard has none

Douglas Crockford, who wrote the format down, took comments out on purpose. He explained it like this: people started to put instructions for their own parser inside the comments, which broke the promise that any JSON reader can read any JSON file. Without comments, that cannot happen.

He also gave the workaround: put the file through a program that removes the comments before you give it to the parser.

Where comments appear anyway

The rule fits a message between two machines. It fits a configuration file badly, because a configuration file is read by people and needs an explanation.

So the big tools broke the rule:

• Visual Studio Code reads comments in settings.json and in every .json file it owns.
• TypeScript reads comments in tsconfig.json.
• Babel, ESLint and many others read them in their own files.

Microsoft gave the form a name: JSONC, meaning JSON with comments. It is JSON plus // to the end of the line, /* */ across lines, and a trailing comma.

JSON5

JSON5 goes further. It tries to make JSON as comfortable as JavaScript:

{
  // comments, of both kinds
  unquoted: 'and single quotes',
  trailingComma: [1, 2, 3,],
  hexadecimal: 0xdecaf,
  leadingDecimal: .8675309,
  positive: +1,
  notANumber: NaN,
  multiline: "a line \
continues here",
}

JSON5 is a different format with its own standard. A JSON parser cannot read it. Use it only where the tool asks for it.

The three forms side by side

What to do in practice

For a message between programs: no comments. Nothing in the message needs an explanation at the moment it is read. Keep it strict.

For a configuration file people edit: comments help. Pick one of these:

1. Use the .jsonc name. The editor then knows, and so does the next person.
2. Put the explanation in the data. A key such as "_comment" is valid JSON that every parser reads. It is clumsy but it always works.
3. Use another format. YAML and TOML both have comments and both are made for configuration. If the file is only ever read by people and by your own program, this is often the better answer.

Reading a file that holds comments

Most online viewers refuse the file. They are correct by the standard and useless to you.

This viewer reads comments by default:

• A comment shows in the tree, next to the value it belongs to, in a quiet colour.
• Format keeps the comments.
• Remove white space drops them, because the result must be valid JSON.
• A Strict JSON switch in the options makes the reader refuse them, the same as the standard does. Turn it on when you must be certain a file is valid JSON.

The same switch controls trailing commas, single quotation marks and keys without quotation marks. With it off, the viewer reads all of them, and Format writes correct JSON back out. That makes the tool a quick way to turn a JSON5-like file into a strict one.

Removing comments before a parser sees them

If a tool in your chain refuses the file, strip the comments first. Do not write the regular expression yourself: a // inside a text value must stay, and a simple pattern removes it and breaks the file.

# Node, with the library Visual Studio Code uses
npx strip-json-comments-cli config.jsonc > config.json

# Python
import json5            # or: pip install commentjson
data = json5.loads(open('config.jsonc').read())

In this viewer the same job takes two clicks: open the file and press Remove white space, or press Format with Keep comments turned off in the options. The output is strict JSON that any parser reads, and the single quotation marks, the bare keys and the trailing commas are corrected at the same time.

A note on // inside a string

This is valid JSON, and the // is part of the data:

{ "url": "https://example.com/api" }

A reader that removes comments with a plain search for // destroys that value. A correct reader tracks whether it is inside a string. The viewer does, which is why a URL survives both the tree and the format.

In short

• The standard has no comments, and that will not change.
• JSONC is JSON with comments and a trailing comma. Many tools use it.
• JSON5 adds much more and needs its own parser.
• For a configuration file, comments are worth the cost. For a message between programs, they are not.

Read next