97

According to Crockford's json.org, a JSON object is made up of members, which is made up of pairs.

Every pair is made of a string and a value, with a string being defined as:

A string is a sequence of zero or more Unicode characters, wrapped in double quotes, using backslash escapes. A character is represented as a single character string. A string is very much like a C or Java string.

But in practice most programmers don't even know that a JSON key should be surrounded by double quotes, because most browsers don't require the use of double quotes.

Does it make any sense to bother surrounding your JSON in double quotes?

Valid Example:

{
  "keyName" : 34
}

As opposed to the invalid:

{
   keyName : 34
}
Kevin Brown-Silva
  • 40,873
  • 40
  • 203
  • 237
Mark Rogers
  • 96,497
  • 18
  • 85
  • 138
  • 22
    "Why bother to do it right?" This is the kind of lazy thinking that leads to websites laden with invalid markup. Future-proof your code in case some browser *does* require double quotes. – user229044 Nov 17 '10 at 04:19
  • 23
    "Why bother to do it right?" - Why bother to follow a convention that no one else does, if there is no real benefit? Perhaps you confuse lazy thinking with pragmatism. – Mark Rogers Nov 17 '10 at 04:22
  • 18
    @Mark - "that no one else does"...where did you get that idea? the JSON serializer built into **every** major platform does proper quoting. – Nick Craver Nov 17 '10 at 04:23
  • @Nick Craver - Ask your average web developer, you'll probably get a suspicious stare. Because most browsers allow for invalid json most do not know of this requirement for validity. – Mark Rogers Nov 17 '10 at 04:38
  • 7
    @Mark Rogers PHP json_encode function produces valid JSON, with double quoted strings, for instance. Maybe you're thinking of object literals in JavaScript? True that those work without quoting the keys, but that's not JSON. – JAL Nov 17 '10 at 05:06
  • 1
    @Mark - *No* browsers allow for invalid JSON in their `JSON.parse()` (what *else* would you use?), I showed a demo of this in the answer below. – Nick Craver Nov 17 '10 at 09:46
  • 11
    For the record, years ago when I posted this, I was confused about the difference between JSON and object literal notation as @JAL suggested. The two have a very similar syntax, this ultimately led to some confusion in describing the issue. – Mark Rogers Apr 15 '15 at 18:18
  • 1
    @MarkRogers Maybe you should mention this misunderstanding as an edit to the original question? Otherwise, this may confuse some people. – ba_ul Aug 29 '15 at 03:32
  • 1
    @ba_ul - I prefer to leave it this way so that people can follow the reasoning, starting from the misunderstanding. – Mark Rogers Aug 29 '15 at 14:25

4 Answers4

170

The real reason about why JSON keys should be in quotes, relies in the semantics of Identifiers of ECMAScript 3.

Reserved words cannot be used as property names in Object Literals without quotes, for example:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

While if you use quotes the property names are valid:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

The own Crockford explains it in this talk, they wanted to keep the JSON standard simple, and they wouldn't like to have all those semantic restrictions on it:

....

That was when we discovered the unquoted name problem. It turns out ECMA Script 3 has a whack reserved word policy. Reserved words must be quoted in the key position, which is really a nuisance. When I got around to formulizing this into a standard, I didn't want to have to put all of the reserved words in the standard, because it would look really stupid.

At the time, I was trying to convince people: yeah, you can write applications in JavaScript, it's actually going to work and it's a good language. I didn't want to say, then, at the same time: and look at this really stupid thing they did! So I decided, instead, let's just quote the keys.
That way, we don't have to tell anybody about how whack it is.

That's why, to this day, keys are quoted in JSON.

...

The ECMAScript 5th Edition Standard fixes this, now in an ES5 implementation, even reserved words can be used without quotes, in both, Object literals and member access (obj.function Ok in ES5).

Islam Hassan
  • 673
  • 1
  • 10
  • 21
Christian C. Salvadó
  • 807,428
  • 183
  • 922
  • 838
  • 2
    @Mark, you're welcome. Keep in mind that JSON is simply a *language-agnostic* data interchange format, even if its syntax was inspired by the Javascript Object Literal syntax, there are differences between them (a lot more than just the quoted keys). – Christian C. Salvadó Nov 17 '10 at 06:39
  • 2
    @CMS, So why must it be only double quotes? Why are single quotes invalid in JSON? – Pacerier May 02 '14 at 16:59
  • 1
    Single quotes are disallowed to keep the JSON standard as simple as possible. JSON only needs to be a subset of Javascript, it does not need to implement as much of Javascript as possible. – thomasrutter Aug 10 '17 at 02:24
  • The [JSON5 superset spec](https://stackoverflow.com/a/61599957/8910547) adheres to ES5 syntax and thus supports unquoted keys amongst other things. The library has compatible `parse` and `stringify` methods. – Inigo May 04 '20 at 19:43
  • In that compatibility table link (at the bottom of the answer) the *Reserved words* entry is under the **Object/array literal extensions** section. And TL;DR, all listed browsers (all you've heard of and about 20 more) all say "Yes". – i336_ Jun 29 '20 at 15:46
17

Yes, it's invalid JSON and will be rejected otherwise in many cases, for example jQuery 1.4+ has a check that makes unquoted JSON silently fail. Why not be compliant?

Let's take another example:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

...all of these would be valid with quotes, why not be consistent and use them in all cases, eliminating the possibility of a problem?

One more common example in the web developer world: There are thousands of examples of invalid HTML that renders in most browsers...does that make it any less painful to debug or maintain? Not at all, quite the opposite.

Also @Matthew makes the best point of all in comments below, this already fails, unquoted keys will throw a syntax error with JSON.parse() in all major browsers (and any others that implement it correctly), you can test it here.

Community
  • 1
  • 1
Nick Craver
  • 623,446
  • 136
  • 1,297
  • 1,155
  • Yep, I had some old ajax apps generating schonky json server-side, which failed when upgraded to jquery 1.4 due to the lack of double quotes around key names. – JAL Nov 17 '10 at 04:23
  • You might want to add that all the major browsers' `JSON.parse` will also correctly reject it. – Matthew Flaschen Nov 17 '10 at 04:24
  • I'm curious, in what case exactly will JQuery 1.4 silently fail with this type of invalid json? – Mark Rogers Nov 17 '10 at 04:24
  • 1
    @Mark - In any case it's not properly quoted or has invalid characters...basically it'll fail with any invalid JSON. – Nick Craver Nov 17 '10 at 04:27
  • That's interesting, that hasn't been my experience with JQuery 1.4. Furthermore, I don't think jquery is responsible for creating json objects, is that not what the browser's javascript interpreter does? Are you referring to Jquery json deserialization? – Mark Rogers Nov 17 '10 at 04:40
  • @Mark Rogers Yes, it fails in deserialization. That's what I was referring to in my comment - I had a PHP page sending json like `{cow:47,duck:"flapping left"}` and when retrieved via $.getJSON or $.ajax with dataType json, with a Content-Type of application/json, it failed. The data was decoded to `null`. However, this invalid json worked fine in jQuery 1.3.x. – JAL Nov 17 '10 at 05:03
0

If I understand the standard correctly, what JSON calls "objects" are actually much closer to maps ("dictionaries") than to actual objects in the usual sense. The current standard easily accommodates an extension allowing keys of any type, making

{
    "1" : 31.0,
      1 : 17,
     1n : "valueForBigInt1"
}

a valid "object/map" of 3 different elements.

If not for this reason, I believe the designers would have made quotes around keys optional for all cases (maybe except keywords).

Mario Rossi
  • 7,651
  • 27
  • 37
-4

YAML, which is in fact a superset of JSON, supports what you want to do. ALthough its a superset, it lets you keep it as simple as you want.

YAML is a breath of fresh air and it may be worth your time to have a look at it. Best place to start is here: http://en.wikipedia.org/wiki/YAML

There are libs for every language under the sun, including JS, eg https://github.com/nodeca/js-yaml

user1649339
  • 35
  • 2