Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use strict JSON when a file must work with general-purpose JSON parsers or be exchanged as standard JSON data. Use JSONC when the program that reads the file explicitly supports it and comments would help people maintain the configuration. Decide by checking the consuming program’s documented syntax—not by relying on a filename extension.
What is the difference between JSON and JSONC?
JSON is a standardized, language-independent format for representing and exchanging data. RFC 8259 defines its grammar, registers application/json as its media type, and associates the .json file extension with JSON text. A conforming JSON parser must accept texts that follow that grammar. RFC 8259, an IETF Internet Standard edited by Tim Bray and published in December 2017, states: “A JSON parser MUST accept all texts that conform to the JSON grammar.”
JSONC means “JSON with Comments.” The JSONC specification defines it as an extension of JSON that adds JavaScript-style comments: single-line comments beginning with // and block comments enclosed by /* and */. The specification says comments are ignored during parsing, so removing them should leave the same JSON value representation. They are for people reading the configuration; they do not become part of the parsed data.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteThat extension is the key distinction: comments are not part of standard JSON. A parser may support extra syntax, but RFC 8259 does not require it to accept comments or other non-JSON forms. The RFC allows implementations to accept extensions, which makes that acceptance an implementation choice. A file that works as JSONC in one application may therefore fail when passed to a strict JSON parser.
#1 Best Overall
In practice, “which format is better?” is not a question about which one can represent more data. JSONC comments do not add fields or change the JSON value that remains after parsing. The choice is about the file’s contract: which program consumes it, what grammar that program accepts, and whether the file must travel to other software that expects standard JSON.
| Decision | JSON | JSONC |
|---|---|---|
| Comments | Not part of the JSON grammar. | Supports // and /* ... */ comments. |
| Parser compatibility | Use when consumers require standard JSON. | Use only when the consuming program documents support. |
| Human-maintained configuration | Keep explanations outside the JSON text or store them as actual data fields. | Comments can explain settings without adding fields to the parsed value. |
| Trailing commas | Do not use. | Support is optional and varies among parsers; avoid them for portability. |
| Typical extension and media type | .json and application/json. |
The JSONC draft recommends .jsonc and application/jsonc. |
Can a JSON file have comments?
Not if it must remain valid standard JSON. A comment inserted into a JSON document makes it invalid under the standard JSON grammar, even if a particular editor or application accepts it as an extension. For example, this is strict JSON:
{
"port": 8080,
"enabled": true
}This is JSONC, not strict JSON:
{
// The service listens on this port.
"port": 8080,
"enabled": true
}JSONC also permits block comments, which begin with /* and end with */. For example, /* Keep this setting enabled for the configured service. */ is a comment form supported by the JSONC specification. Both forms are ignored during JSONC parsing. Neither form is safe to assume in a file that is promised to be standard JSON.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteIf the consumer uses a JSONC parser, the comment can help maintainers understand why a setting exists. If the consumer expects standard JSON, the commented example will fail unless the comment is removed before the file reaches that parser. Renaming the file does not transform its contents or make an incompatible parser accept them. A filename can signal a convention, but it cannot change the grammar the application actually implements.
When strict JSON is required but people need documentation, keep the explanation in a README or other documentation, or represent it as a data field only when the receiving application’s schema permits that field. A comment is not data: JSONC parsing ignores it, so the resulting JSON value contains no record of the explanation. Adding an explanatory field is not equivalent to a comment: it changes the data and may affect what the consumer receives or accepts.
That distinction is useful when configuration is consumed in more than one place. If one tool reads the original file as JSONC but another expects strict JSON, the comment-bearing file cannot simply be assumed to work for both. Confirm whether the downstream consumer supports JSONC, or keep the shared artifact strict and put human-facing explanations alongside it.
How to choose the format for a configuration file
- Identify the reader. Find the application, runtime, build tool, or service that actually loads the file. Check that tool’s documentation for the accepted syntax; an editor recognizing a file does not prove the runtime parser will accept it. If several programs read the same file, check the documented requirements of each rather than stopping at the first editor that opens it.
- Check the contract. If the file is exchanged with other systems, submitted to a generic JSON API, or required to follow a standard JSON contract, keep it strict JSON: no comments and no trailing commas. The contract is more important than whether a particular local parser happens to be permissive.
- Use JSONC only with documented support. For a human-maintained configuration, comments are useful when the specific consumer supports JSONC. Follow that tool’s conventions, including any required filename. A desire to annotate the file is not itself evidence that the consuming application accepts comments.
- Choose an extension deliberately. For a standalone JSONC file, the JSONC draft recommends
.jsoncand advises against using.jsonunless a mode line identifies the file. A consuming tool may require a particular name, so its contract takes precedence. Do not rename a tool-managed configuration just to follow a general naming recommendation if the tool expects a specific filename. - Check how the file is transmitted. Use the media type expected by the recipient. The JSONC draft recommends
application/jsoncfor JSONC and warns against labeling commented or otherwise extended content asapplication/json. For standard JSON, RFC 8259 registersapplication/json. - Test with the actual consumer. Validate the file using the parser or application that will load it, not only the editor that displays it. This catches differences in accepted extensions, filenames, and trailing-comma behavior. If editor validation is also part of the workflow, treat it as a separate check rather than a substitute for runtime compatibility.
A quick decision rule follows from those checks. For data that must pass between generic JSON tools, choose JSON. For a configuration maintained by people and read by a tool that explicitly documents JSONC support, JSONC can be a practical choice. When support is unclear, ask which parser is in the path and verify its documented behavior before adding comments.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Why the filename alone cannot tell you which syntax is accepted
A .json extension is a naming convention, not a guarantee that the file contents meet the JSON standard or that every tool will parse them the same way. VS Code’s own configuration files demonstrate the mismatch: its JSON documentation describes JSONC mode for files including settings.json, tasks.json, and launch.json. Those files can contain comments because VS Code handles them as its configuration format.
The VS Code JSON language server distinguishes documents parsed and validated as JSON from JSONC documents, which additionally accept line and block comments. Its README characterizes JSONC as a VS Code-specific format intended for VS Code configuration files. That behavior does not establish support in unrelated tools that happen to read a file ending in .json. Nor should an example from one application be treated as a universal rule for all files using that extension.
The same principle applies to other configuration names. The TypeScript handbook describes tsconfig.json as identifying a TypeScript project’s root and specifying root files and compiler options. The filename tells you what role the file serves, but the consuming tool’s documentation is what you should consult to determine the supported syntax. In other words, the familiar suffix is not a parser specification.
The JSONC draft recommends .jsonc for standalone JSONC files and says to avoid .json unless a mode line identifies the file. That recommendation helps distinguish formats when you control the filename. It does not override a tool’s required configuration name, as VS Code’s own JSON-named files illustrate. Follow the actual consumer’s convention where it specifies one.
JSONC comments and trailing commas are separate choices
Support for JSONC comments does not mean every JSONC parser accepts every commonly seen extension. In particular, trailing commas are optional behavior, not a feature that the JSONC specification requires. A file with a trailing comma may work in one environment and fail in another. Do not infer acceptance of one extension from support for another.
The JSONC specification notes that jsonc-parser rejects trailing commas by default unless configured otherwise. VS Code accepts trailing commas in its JSONC mode but generally displays a warning. For files that may move between JSONC parsers, omit trailing commas even when comments are supported.
This distinction matters when diagnosing errors: a tool may accept comments but still reject a trailing comma. Conversely, a permissive parser may accept both, but that does not make the file portable or valid standard JSON. Keep to the smallest syntax the target consumer documents.
For portability, that means two separate checks: first, whether comments are supported by every intended reader; second, whether trailing commas are supported by every intended reader. The safer cross-tool choice is to avoid trailing commas, since JSONC does not require parsers to accept them. If a file must be strict JSON, avoid both comments and trailing commas.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →What JSONC support in VS Code provides—and what it does not
VS Code’s JSON support can provide IntelliSense, formatting, navigation, and structural and value validation using JSON Schema. Its shipped support covers schema drafts 4 through 7, with limited support for drafts 2019-09 and 2020-12. These editor features can make a configuration easier to author, but they are distinct from the syntax accepted by the program that ultimately reads the file.
VS Code supports schema association through settings and extensions. Adding a $schema key directly to a configuration file is another option in some contexts, but it changes the file’s data. If the consuming application expects a particular structure, an extra key may be unexpected or invalid. Keep editor-only validation choices separate from the runtime configuration contract.
It is helpful to think of these as different layers. A JSONC-aware editor can recognize comments and offer authoring help; a schema can check structure and values; and the runtime application still has its own parser and configuration rules. Success at one layer does not guarantee success at the next. Validate against the actual configuration consumer, especially when the file is used outside the editor that helped create it.
File extensions and media types: follow the consumer’s contract
For standard JSON text, RFC 8259 registers application/json and the .json extension. The JSONC specification recommends the corresponding .jsonc extension and application/jsonc media type for JSONC. It cautions against sending JSONC as application/json, because a strict JSON consumer may reject comments or trailing commas.
The JSONC specification labels itself a draft, so treat its extension and media-type guidance as recommendations rather than a universally adopted policy. In practice, a documented requirement from the program receiving the file determines what filename and media type to use. Do not assume all tools recognize .jsonc or accept application/jsonc.
For a file that stays within a single tool’s configuration system, the tool may have a prescribed name even if it contains JSONC syntax. For a standalone file that you name and transmit yourself, the draft’s recommendation makes the format clearer to a human reader and to a consumer that recognizes the media type. In either case, the label should match the receiving system’s contract; it is not a way to make unsupported syntax acceptable.
Common mistakes and how to avoid them
- Adding a comment to a file that is still sent as ordinary JSON. Remove the comment or confirm that the recipient accepts JSONC and that its contract permits it.
- Assuming an editor’s syntax highlighting proves runtime compatibility. Test with the actual application or parser that loads the file.
- Inferring support from
.jsonor.jsonc. Confirm the documented format and filename for the target tool; extensions do not establish parser behavior. - Using trailing commas because comments work. Treat trailing commas as a separate, inconsistently supported extension and omit them when portability matters.
- Adding
$schemaonly to improve editor help without checking the consumer. The key becomes part of the configuration data and may not be accepted by the application. - Labeling JSONC as
application/jsonduring transmission. Use the recipient’s required media type; the JSONC draft recommendsapplication/jsoncfor JSONC. - Putting explanations in JSON data fields without checking the schema. A field changes the parsed value, unlike an ignored JSONC comment, and may violate the application’s expected structure.
- Treating JSONC as one uniform parser behavior. Comment support and trailing-comma support are not identical guarantees; check each syntax feature against the parser’s documentation.
A practical rule for teams
Choose the format at the boundary where the file is consumed. If it is a private configuration file for a tool that explicitly documents JSONC support, comments can make intent and maintenance notes easier to keep alongside settings. If it is an interchange file, an API payload, or a file read by generic JSON software, use strict JSON and put explanations elsewhere.
For shared repositories, make the rule visible to everyone who edits or validates the file: document the expected parser, any required filename, and whether comments are permitted. A file may be convenient to edit in an IDE yet still be consumed by a stricter downstream process. When in doubt, the safest portable choice is strict JSON without comments or trailing commas.
Recommended Free Tools
Teams can make the decision concrete by recording the configuration contract next to the file or in project documentation: the consuming program, its accepted syntax, any required name, and the validation step contributors should run. This avoids relying on assumptions carried over from a different editor or tool. If the file is intentionally JSONC, identify that convention clearly and confirm it remains compatible with every program that reads it.
Frequently Asked Questions
Can JSON files have comments?
Not if they need to remain valid standard JSON. Comments are outside the JSON grammar. A tool may accept comments as an extension, but that file is then being read as JSONC or another permissive variant, not as strict JSON.
Does renaming a .json file to .jsonc make it valid JSONC?
No. The extension does not alter the contents or parser behavior. Use the syntax the consuming program supports, and follow its required filename. The JSONC draft recommends .jsonc for standalone JSONC files, but an application may prescribe another name.
Does my parser support JSONC?
Check the documentation for the application or parser that actually loads the file. Do not infer support from the editor, syntax highlighting, or file extension. If multiple tools consume the file, check each one.
Are trailing commas valid in JSONC?
They are optional behavior, not something the JSONC specification requires every parser to support. The jsonc-parser default rejects them unless configured otherwise; VS Code accepts them in JSONC mode but generally warns about them. Omit them when portability matters.
Can I use JSONC in VS Code configuration files?
VS Code’s JSON documentation describes JSONC mode for configuration files such as settings.json, tasks.json, and launch.json. That support is specific to the relevant VS Code configuration context; it does not mean unrelated programs accept comments in files with .json names.
Should I use JSON or JSONC for an API payload or shared data file?
Use strict JSON when the recipient expects standard JSON or the file is exchanged with generic JSON software. JSONC comments are not part of the standard grammar, and a strict consumer may reject them. Follow the recipient’s media-type contract as well.
Can I add a $schema key to get editor validation?
VS Code supports schema association through settings and extensions, and in some contexts a $schema key can associate a schema. But that key becomes part of the configuration data and may be unexpected or invalid for the consuming application. Check the application’s contract first.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The Bottom Line
Use strict JSON for standard data exchange or whenever the consumer requires the JSON grammar. Use JSONC only when the consuming tool explicitly supports it and comments are useful. Check the actual parser, filename, and media-type requirements; omit trailing commas when portability matters.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
