Can I use comments inside a JSON file? If so, how?
57 Answers
No.
JSON is data-only. If you include a comment, then it must be data too.
You could have a designated data element called "_comment" (or something) that should be ignored by apps that use the JSON data.
You would probably be better having the comment in the processes that generates/receives the JSON, as they are supposed to know what the JSON data will be in advance, or at least the structure of it.
But if you decided to:
{
"_comment": "comment text goes here...",
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}
You can't. At least that's my experience from a quick glance at json.org.
JSON has its syntax visualized on that page. There isn't any note about comments.
The idea behind JSON is to provide simple data exchange between applications. These are typically web based and the language is JavaScript.
It doesn't really allow for comments as such, however, passing a comment as one of the name/value pairs in the data would certainly work, although that data would obviously need to be ignored or handled specifically by the parsing code.
All that said, it's not the intention that the JSON file should contain comments in the traditional sense. It should just be the data.
Have a look at the JSON website for more detail.
Yes, the new standard, JSON5 allows the C++ style comments, among many other extensions:
// A single line comment.
/* A multi-
line comment. */
The JSON5 Data Interchange Format (JSON5) is a superset of JSON that aims to alleviate some of the limitations of JSON. It is fully backwards compatible, and using it is probably better than writing the custom non standard parser, turning non standard features on for the existing one or using various hacks like string fields for commenting. Or, if the parser in use supports, simply agree we are using JSON 5 subset that is JSON and C++ style comments. It is much better than we tweak JSON standard the way we see fit.
There is already npm package, Python package, Java package and C library available. It is backwards compatible. I see no reason to stay with the "official" JSON restrictions.
I think that removing comments from JSON has been driven by the same reasons as removing the operator overloading in Java: can be used the wrong way yet some clearly legitimate use cases were overlooked. For operator overloading, it is matrix algebra and complex numbers. For JSON comments, its is configuration files and other documents that may be written, edited or read by humans and not just by parser.
The Dojo Toolkit JavaScript toolkit (at least as of version 1.4), allows you to include comments in your JSON. The comments can be of /* */ format. Dojo Toolkit consumes the JSON via the dojo.xhrGet() call.
Other JavaScript toolkits may work similarly.
This can be helpful when experimenting with alternate data structures (or even data lists) before choosing a final option.
Disclaimer: This is silly
There is actually a way to add comments, and stay within the specification (no additional parser needed). It will not result into human-readable comments without any sort of parsing though.
You could abuse the following:
Insignificant whitespace is allowed before or after any token. Whitespace is any sequence of one or more of the following code points: character tabulation (U+0009), line feed (U+000A), carriage return (U+000D), and space (U+0020).
In a hacky way, you can abuse this to add a comment. For instance: start and end your comment with a tab. Encode the comment in base3 and use the other whitespace characters to represent them. For instance.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(hello base three in ASCII) But instead of 0 use space, for 1 use line feed and for 2 use carriage return.
This will just leave you with a lot of unreadable whitespace (unless you make an IDE plugin to encode/decode it on the fly).
I never even tried this, for obvious reasons and neither should you.
JSON doesn't allow comments, per se. The reasoning is utterly foolish, because you can use JSON itself to create comments, which obviates the reasoning entirely, and loads the parser data space for no good reason at all for exactly the same result and potential issues, such as they are: a JSON file with comments.
If you try to put comments in (using
//or/* */or#for instance), then some parsers will fail because this is strictly not within the JSON specification. So you should never do that.
Here, for instance, where my image manipulation system has saved image notations and some basic formatted (comment) information relating to them (at the bottom):
{
"Notations": [
{
"anchorX": 333,
"anchorY": 265,
"areaMode": "Ellipse",
"extentX": 356,
"extentY": 294,
"opacity": 0.5,
"text": "Elliptical area on top",
"textX": 333,
"textY": 265,
"title": "Notation 1"
},
{
"anchorX": 87,
"anchorY": 385,
"areaMode": "Rectangle",
"extentX": 109,
"extentY": 412,
"opacity": 0.5,
"text": "Rect area\non bottom",
"textX": 98,
"textY": 385,
"title": "Notation 2"
},
{
"anchorX": 69,
"anchorY": 104,
"areaMode": "Polygon",
"extentX": 102,
"extentY": 136,
"opacity": 0.5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Simple polygon",
"textX": 85,
"textY": 104,
"title": "Notation 3"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON image notation data:",
"c02": "-------------------------",
"c03": "",
"c04": "This data contains image notations and related area",
"c05": "selection information that provides a means for an",
"c06": "image gallery to display notations with elliptical,",
"c07": "rectangular, polygonal or freehand area indications",
"c08": "over an image displayed to a gallery visitor.",
"c09": "",
"c10": "X and Y positions are all in image space. The image",
"c11": "resolution is given as imageXW and imageYW, which",
"c12": "you use to scale the notation areas to their proper",
"c13": "locations and sizes for your display of the image,",
"c14": "regardless of scale.",
"c15": "",
"c16": "For Ellipses, anchor is the center of the ellipse,",
"c17": "and the extents are the X and Y radii respectively.",
"c18": "",
"c19": "For Rectangles, the anchor is the top left and the",
"c20": "extents are the bottom right.",
"c21": "",
"c22": "For Freehand and Polygon area modes, the pointList",
"c23": "contains a series of numbered XY points. If the area",
"c24": "is closed, the last point will be the same as the",
"c25": "first, so all you have to be concerned with is drawing",
"c26": "lines between the points in the list. Anchor and extent",
"c27": "are set to the top left and bottom right of the indicated",
"c28": "region, and can be used as a simplistic rectangular",
"c29": "detect for the mouse hover position over these types",
"c30": "of areas.",
"c31": "",
"c32": "The textx and texty positions provide basic positioning",
"c33": "information to help you locate the text information",
"c34": "in a reasonable location associated with the area",
"c35": "indication.",
"c36": "",
"c37": "Opacity is a value between 0 and 1, where .5 represents",
"c38": "a 50% opaque backdrop and 1.0 represents a fully opaque",
"c39": "backdrop. Recommendation is that regions be drawn",
"c40": "only if the user hovers the pointer over the image,",
"c41": "and that the text associated with the regions be drawn",
"c42": "only if the user hovers the pointer over the indicated",
"c43": "region."
}
}
Sigh. Why not just add fields, e.g.
{
"note1" : "This demonstrates the provision of annotations within a JSON file",
"field1" : 12,
"field2" : "some text",
"note2" : "Add more annotations as necessary"
}
Just make sure your "notex" names don't conflict with any real fields.
The JSON specification does not support comments, // or /* */ style.
But some JSON parsing libraries and IDEs support them.
Like:
JSON does not have comments. A JSON encoder MUST NOT output comments. A JSON decoder MAY accept and ignore comments.
The utility jq includes a decoder that does allow "#"-style comments and so jq is one of several tools that can be used in conjunction with JSON-with-comments files, so long as such files are treated as "jq programs", rather than as JSON files. For example:
$ jq -ncf <(echo $'[1, # one\n2 ] # two')
[1,2]
More importantly, jq can handle very large JSON-with-comments files as programs; this can be illustrated using a well-known JSON file:
$ ls -l JEOPARDY_QUESTIONS1.json
-rw-r--r-- 2 xyzzy staff 55554625 May 12 2016 JEOPARDY_QUESTIONS1.json
$ jq -nf JEOPARDY_QUESTIONS1.json | jq length
216930
The practical answer for Visual Studio Code users in 2019 is to use the 'jsonc' extension.
It is practical, because that is the extension recognized by Visual Studio Code to indicate "JSON with comments". Please let me know about other editors/IDEs in the comments below.
It would be nice if Visual Studio Code and other editors would add native support for JSON5 as well, but for now Visual Studio Code only includes support for 'jsonc'.
(I searched through all the answers before posting this and none mention 'jsonc'.)
json specs doesn't support comments BUT you can work around the problem by writing your comment as keys, like this
{
"// my own comment goes here":"",
"key1":"value 1",
"// another comment goes here":"",
"key 2": "value 2 here"
}
this way we are using the comment texts as keys ensuring (almost) that they are unique and they will not break any parsers. if some of your comments are not unique just add random numbers at the end.
if you need to parse comments to do any processing like stripping them you can fill the comment values with text indicating that it is a comment , like so:
{
"// my own comment goes here" : "_comment",
"key1":"value 1",
"// another comment goes here" : "_comment",
"key 2": "value 2 here"
}
this way a parser can find all comments and process them.
The Pure answer is No.
But some editors and platforms use workarounds to add comments to JSON.
1. Today most editors have built-in options and extensions to add comments to JSON documents. (eg:- VS Code also has a JSON with Comments (jsonc) mode / VS Code also has nice extensions for that)
Link to activate jsonc mode in VsCode
2. Some platforms provide built-in ways to add comments (impure json).
(eg:- In firebase, I can comment firebase.jsons for a while without issue.
{
"hosting": {
"headers": [
/*{
"source": "*.html",
"headers": [
{
"key": "Content-Security-Policy",
"value": "default-src 'self' ..."
}
]
},*/
]
}
}
3. In your own JSON parsing method, you can set a predefined key name as a comment.
eg:-
{
"comment" : "This is a comment",
"//" : "This also comment",
"name" : "This is a real value"
}
*.json files are generally used as configuration files or static data, thus the need of comments → some editors like NetBeans accept comments in *.json.
The problem is parsing content to an object. The solution is to always apply a cleaning function (server or client).
###PHP
$rgx_arr = ["/\/\/[^\n]*/sim", "/\/\*.*?\*\//sim", "/[\n\r\t]/sim"];
$valid_json_str = \preg_replace($rgx_arr, '', file_get_contents(path . 'a_file.json'));
###JavaScript
valid_json_str = json_str.replace(/\/\/[^\n]*/gim,'').replace(/\/\*.*?\*\//gim,'')
Sure you can comment JSON. To read a commented JSON file from JavaScript you can strip comments before parsing it (see the code below). I'm sure this code can be improved, but it is easy to understand for those who use regular expressions.
I use commented JSON files to specify neuron shapes for my synthetic reflex systems. I also use commented JSON to store intermediate states for a running neuron system. It is very convenient to have comments. Don't listen to didacts who tell you they are a bad idea.
fetch(filename).then(function(response) {
return response.text();
}).then(function(commented) {
return commented.
replace(/\/\*[\s\S]*?\*\/|([^\\:]|^)\/\/.*$/gm, '$1').
replace(/\r/,"\n").
replace(/\n[\n]+/,"\n");
}).then(function(clean) {
return JSON.parse(clean);
}).then(function(json) {
// Do what you want with the JSON object.
});
Well at the time of writing, appsettings.json supports comments.
e.g. (sample courtesy of Microsoft)
{
"Logging": {
"LogLevel": { // All providers, LogLevel applies to all the enabled providers.
"Default": "Error", // Default logging, Error and higher.
"Microsoft": "Warning" // All Microsoft* categories, Warning and higher.
},
"Debug": { // Debug provider.
"LogLevel": {
"Default": "Information", // Overrides preceding LogLevel:Default setting.
"Microsoft.Hosting": "Trace" // Debug:Microsoft.Hosting category.
}
},
"EventSource": { // EventSource provider
"LogLevel": {
"Default": "Warning" // All categories of EventSource provider.
}
}
}
}
Although JSON does not support comments, JSONC does.
Name your file with '.jsonc' extension and use a jsonc parser.
Sorry if this answer was too late.
jsonWithComments.jsonc
Example:
{
// This is a comment!
"something": "idk"
}
If this is unclear, I think the bot is weird. Please try before voting this question as unhelpful.
I came across this problem in my current project as I have quite a bit of JSON that requires some commenting to keep things easy to remember.
I've used this simple Python function to replace comments & use json.loads to convert it into a dict:
import json, re
def parse_json(data_string):
result = []
for line in data_string.split("\n"):
line = line.strip()
if len(line) < 1 or line[0:2] == "//":
continue
if line[-1] not in "\,\"\'":
line = re.sub("\/\/.*?$", "", line)
result.append(line)
return json.loads("\n".join(result))
print(parse_json("""
{
// This is a comment
"name": "value" // so is this
// "name": "value"
// the above line gets removed
}
"""))
Yes. You can put comments in a JSON file.
{
"": "Location to post to",
"postUrl": "https://example.com/upload/",
"": "Username for basic auth",
"username": "joebloggs",
"": "Password for basic auth (note this is in clear, be sure to use HTTPS!",
"password": "bloejoggs"
}
A comment is simply a piece of text describing the purpose of a block of code or configuration. And because you can specify keys multiple times in JSON, you can do it like this. It's syntactically correct and the only tradeoff is you'll have an empty key with some garbage value in your dictionary (which you could trim...)
I saw this question years and years ago but I only just saw this done like this in a project I'm working on and I thought this was a really clean way to do it. Enjoy!
I really like @eli 's approach, there are over 30 answers but no one has mentioned lists (array). So using @eli 's approach we could do something like:
"part_of_speech": {
"__comment": [
"@param {String} type - the following types can be used: ",
"NOUN, VERB, ADVERB, ADJECTIVE, PRONOUN, PREPOSITION",
"CONJUNCTION, INTERJECTION, NUMERAL, PARTICLE, PHRASE",
"@param {String} type_free_form - is optional, can be empty string",
"@param {String} description - is optional, can be empty string",
"@param {String} source - is optional, can be empty string"
],
"type": "NOUN",
"type_free_form": "noun",
"description": "",
"source": "https://google.com",
"noun_class": {
"__comment": [
"@param {String} noun_class - the following types can be used: ",
"1_class, 2_class, 3_class, 4_class, 5_class, 6_class"
],
"noun_class": "4_class"
}
}
Comments are needed in JSON and comments ARE available in at least .NET Core JSON and Newtonsoft Json. Works perfectly.
{
// this is a comment for those who is ok with being different
"regular-json": "stuff"...
}
Related