Summary
My VS Code settings.json file is full of notes to myself. One line explains why autosave waits a moment; another reminds me why the build folders are hidden. After adjusting a handful of VS Code settings that make coding feel lighter, those comments are how I remember why each one exists. Yet hand that file to Python’s built-in JSON parser, and it fails on the very first comment. The difference is intentional. Since version 1.19 in November 2017, VS Code has opened its own config files in a separate mode that allows comments on purpose. Your settings file quietly breaks JSON’s rules Comments and trailing commas were never part of the standard JSON, short for JavaScript Object Notation, is the plain-text format countless apps and websites use to pass data around. Its official standard, RFC 8259, allows objects, arrays, strings, numbers, true, false, and null. It doesn’t allow comments, and it doesn’t allow a trailing comma, the extra comma after the last item in a list. That omission was deliberate. Douglas Crockford, who created JSON, has explained that he removed comments because people were using them to hold parsing directives, which threatened interoperability. Yet the settings.json file in my quick-notes project has plenty of both. There are line comments starting with // , a block comment wrapped in /* */ , and trailing commas after the last item in two places. VS Code reports zero problems. The same goes for tasks.json, launch.json, and tsconfig.json, the files you’re most likely to edit by hand. I think that’s the right call. A config file is something you return to months later, and a one-line note explaining why you enabled a setting stops you from turning it off by mistake. Strict JSON would push that context into a separate document that nobody opens. Config files get their own JSONC mode The status bar decides how strict the editor gets The switch lives in the bottom-right corner of the status bar. Open a regular .json file, and the language indicator reads JSON. Open settings.json, and it reads JSON with Comments, usually shortened to JSONC. That one label decides which rules the editor enforces. Microsoft made this choice deliberately. According to Microsoft’s release notes for VS Code 1.19, the new mode was added to separate JSON-like files that allow comments from files that follow the standard. The parsing is handled by node-jsonc-parser, an open-source Microsoft library, which is a nice contrast to the debate over how open-source VS Code itself really is. To see the difference, I saved the same config twice, once as app-config.json and once as app-config.jsonc. The .json copy lit up with four errors. The .jsonc copy showed none, only two yellow warnings. Those warnings are where it gets interesting. In a generic .jsonc file, VS Code flags trailing commas as warnings, matching its documentation, which calls them discouraged. In settings.json and tsconfig.json, the same commas pass silently. VS Code recognizes those files and relaxes the rules even further. That’s a sensible compromise. You add, remove, and reorder lines in config files constantly, and a stray comma after the last item is a common reason a file refuses to load. If one of your own files is stuck in strict mode, click JSON in the status bar and pick JSON with Comments. I tested this on VS Code 1.140 on Windows 11. Trailing commas behave differently from file to file, so check the Problems panel instead of assuming every JSONC file is equally forgiving. Strict parsers won’t forgive those comments The leniency stops the moment a file leaves VS Code I pointed a short Python script at app-config.jsonc, using the built-in json module that follows the official standard. It failed immediately with a JSONDecodeError at line 2, column 3, the exact spot where the first comment begins. Windows PowerShell’s ConvertFrom-Json command rejected the file too. The same trap exists inside VS Code. The package.json file that npm reads to manage a JavaScript project stays in strict JSON mode, so a single comment there gets a red error. The app list you get when rebuilding a Windows setup with Winget’s export and import commands is plain JSON as well. Strict-JSON advocates have a fair point here. Comments invite dialects, and JSONC, JSON5, and HJSON each bend the format in slightly different ways, so a file that works in one tool can fail in the next. But VS Code keeps JSONC inside a named mode and a known set of files. Your data files stay strict, and the status bar tells you which rules apply. In practice, that comes down to two habits. Comment freely in files labeled JSON with Comments, and strip those comments before a file goes to a script, an API, or another app. Treat comments as a config-file privilege Annotate freely, but check the status bar first JSONC looks set to outlast its reputation as a VS Code quirk. A community specification has been in draft since September 2025, which suggests other tools may eventually agree on the same rules. Until then, I’d treat comments as a privilege that comes with config files. Record why you changed a setting, keep your data files strict, and glance at the language mode before copying a config anywhere else. The rule-breaking works because it’s deliberate and contained. And once your settings file is tidy, the VS Code extensions worth installing early are a good next stop.