Before you answer, yes I know that other languages have no native javascript object support, but neither do they have native support for json.

So wouldn't it make much more sense to modify the json spec to allow identifiers without "" and allow comments? Very sensible things because you don't have to serialize/deserialize when working in javascript, no?

  • why do you think it's "sensible"?
    – gnat
    Feb 18, 2014 at 13:08
  • because you dont' have to serialize/deserialize when working in javascript
    – Blub
    Feb 18, 2014 at 13:12
  • @Blub JSON isn't only used in JavaScript, it's a common config file format as well. And you do have to serialize your object when you want to send it to another program (e.g. an API request to a server). There are also some security reasons why JSON should be parsed, not eval'd.
    – amon
    Feb 18, 2014 at 13:18
  • you would still have to serialize/deserialize, since a javascript object would have to be written as text, and an incoming text would have to be parsed to be operated. no gain at all.
    – Javier
    Feb 18, 2014 at 14:46

2 Answers 2


JSON is a data interchange/serialization format. It's not code intended to be written by humans, but human-readability is important. Given these requirements, JSON is the simplest subset of JavaScript that could possibly work.

For example, we need to allow quoted keys in objects. But if we already have a quoted syntax, there is no need to support unquoted keys as well. Likewise, JSON knows only "..." double quoted strings, single quoted strings '...' do not exist.

The result is that it's really easy to implement a JSON parser (maybe 20 lines with a nice parser generator). We wouldn't want to throw that advantage away (which helped become JSON so accepted. Contrast with the complexities of parsing XML). Of course, a production-ready implementation should be lenient in what it accepts.

Could a change like this be retro-fitted into the standard? No, because backwards compatibility. Feel free to write a JSON implementation that accepts unquoted keys, but you can never emit such a string, in case the receiver uses a stricter implementation. And because you generate all your JSON via a library instead of writing it per hand, adding those quotes isn't any extra burden.

  • 2
    No "of course" about being lenient. I think Postel's law was a mistake. Be strict in what you accept, and authors of other implementations will notice their bugs earlier. Feb 18, 2014 at 13:30
  • 2
    JSON is also used for configuration files, which are often written by hand. Just because it is usually serialized from an object doesn't mean it always will be.
    – DougM
    Feb 18, 2014 at 13:33
  • JSON is nearly but not quite a subset of JavaScript. To fully implement the standard in JavaScript, it has to be parsed. Once this is so, the original justification for many features falls away. Only the existence of legacy code means change is no longer possible.
    – david.pfx
    Feb 18, 2014 at 14:14
  • @david.pfx in what aspect is JSON not a subset of JS? the fact that JavaScript shouldn't just eval is only because of safety, not because JSON has any deviations from the JS format.
    – Javier
    Feb 18, 2014 at 14:50
  • 2
    @Javier: Thought you'd never ask. See timelessrepo.com/json-isnt-a-javascript-subset. Close but no cigar, to quote the man. Rumour is that ES5 will fix it.
    – david.pfx
    Feb 19, 2014 at 3:47

The reason for this is because you would still have to do an eval for deserialization and you would still have to somehow deserialize the javascript object into a string, which it doesnt just to by default. Also there is a general argument against using eval - particularly for an exchange format, since javascript objects are also functions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.