What is the difference between object keys with quotes and without quotes?

Is there any difference between

obj = {'foo': 'bar'} 


obj = {foo: 'bar'}

I have noticed that you can't use - in the key when I don't use the quotes. But does it actually make a difference? If yes, which?

No, the quotes do not make a difference (unless, as you noted, you want to use a key that’s not a valid JavaScript identifier).

As a side note, the JSON data exchange format does require double quotes around identifiers (and does not allow single quotes).

From Unquoted property names / object keys in JavaScript, my write-up on the subject:

Quotes can only be omitted if the property name is a numeric literal or a valid identifier name.


Bracket notation can safely be used for all property names.


Dot notation can only be used when the property name is a valid identifier name.

Note that reserved words are allowed to be used as unquoted property names in ES5. However, for backwards compatibility with ES3, I’d suggest quoting them anyway.

I also made a tool that will tell you if any given property name can be used without quotes and/or with dot notation. Try it at mothereff.in/js-properties.


There is no difference here. Just a matter of style. One of the reasons for doing this is being able to use 'super' or 'class' as a key since those are reserved keywords.

Some people might be tempted to pass in a string with whitespace then call o['I can have whitespace'] But I would call that bad practice.

No, not to javascript. However, some JSON parsers will fail when the quotes around the keys are not present.

There are some situations where they are different. For example, if you are using jQuery, and you are making a list of parameters to pass when calling the jQuery $() command to create an element, quoted words are turned into parameters, and non-quoted words are turned into functions. For example, "size" will set the size attribute of the object, and size (no quotes), will call the size() function on the object. See jQuery(), near the bottom:

While the second argument is convenient, its flexibility can lead to unintended consequences (e.g. $( "<input>", {size: "4"} ) calling the .size() method instead of setting the size attribute). The previous code block could thus be written instead as: