Which characters are valid/invalid in a JSON key name?

Question

Are there any forbidden characters in key names, for JavaScript objects or JSON strings? Or characters that need to be escaped?

To be more specific, I'd like to use "$", "-" and space in key names.

Solution 1

No. Any valid string is a valid key. It can even have " as long as you escape it:

{"The \"meaning\" of life":42}

There is perhaps a chance you'll encounter difficulties loading such values into some languages, which try to associate keys with object field names. I don't know of any such cases, however.

Solution 2

The following characters must be escaped in JSON data to avoid any problems:

• " (double quote)
• \ (backslash)
• all control characters like \n, \t

JSON Parser can help you to deal with JSON.

Solution 3

It is worth mentioning that while starting the keys with numbers is valid, it could cause some unintended issues.

Example:

var testObject = {
    "1tile": "test value"
};
console.log(testObject.1tile); // fails, invalid syntax
console.log(testObject["1tile"]; // workaround

Solution 4

Unicode codepoints U+D800 to U+DFFF must be avoided: they are invalid in Unicode because they are reserved for UTF-16 surrogate pairs. Some JSON encoders/decoders will replace them with U+FFFD. See for example how the Go language and its JSON library deals with them.

So avoid "\uD800" to "\uDFFF" alone (not in surrogate pairs).

View more solutions

Comments

[invalidsyntax]

I think partially this answer has to do with the way you're encoding. For example, UTF8 has different characters allowed versus ANSI.

[Marc B]

You can use any 'key' you want in JS using the obj['whatever'] notation. But only regular alphanumeric keys can be used for the obj.whatever version.

[Alex S]

@invalidsyntax: JSON is Unicode by definition. Also, ANSI isn't an encoding, it's a character set, so the comparison should be Unicode-vs-ANSI, not UTF-8-vs-ANSI.

[Trinidad]

Old discussion but, ASCII (what people often refer to by ANSI) is an encoding and on top of that it also defines a character set.

[Christophe]

Thx! Any other characters that would need to be escaped? Like : or ; ?

[Alex S]

Not those. Whatever needs escaping in JavaScript generally needs it in JSON. Best to get it from the horse's mouth, though, at json.org. It takes about one minute to read the entire spec end-to-end.

[Alex KeySmith]

Hi Arun, single quotes do not need to be escaped. Infact escaping them will cause strict JSON parsers to throw an exception. Refer to the string section of json.org Of course however you will need to escape them when inside a JSON string (but not the JSON itself).

[Adrien Be]

@AlexKey you're completely right! Arun, you can check this on jsonlint.com by testing the JSON { "singlequotetest": "something here isn\'t right"} versus { "singlequotetest": "Fixing here what wasn't right"}

[Alex KeySmith]

@Arun Rana - no worries.

[Abhi]

{ "*~@#$%^&*()_+=><?/": "is a valid json" }

[Daniel W.]

This is not a good answer imho. Which kind of characters need to be escaped? Which characters can be escaped, but don't have to be escaped?

[Alex S]

{"🐶🔫": "not nice, but still valid json"}

[mtraceur]

Can anyone clarify if this includes things like the Unicode null character (U+0000, plain "null byte" in UTF-8), etc? The both json.org and the linked official/formal ECMA specification PDF seem to imply that yes, those are valid in JSON, even in their literal forms (not just in the \u four-hex-digits form).

[mr5]

You only need to escape special ASCII characters if you want to present it "as is". We escape single and double quotes only to tell the parser/compiler that it is not the enclosing pair.

[monsto]

I really hope that, in this 2017/18 age of Microsoft, they are regretful of all the pain that they have inflicted.

[Jon Luzader]

Look at their metrics ID parameters: dev.applicationinsights.io/apiexplorer/… ---15 or 20 of their fields have multiple forward slashes in their json field names. While Karns solution works for a specific field, I can't seem to get it to work for a sub-field of 1tile. E.g., a subsequent dot returns undefined for me.

[Chris Rollins]

@mtraceur I was wondering the same thing. I tested in chrome's console and it doesn't like a key with null terminators in it. puu.sh/zJMIS/3d15c6d8e5.png It may not be mentioned in the spec, but don't expect parsers to accept it. best to avoid any ascii control characters I think.

[mtraceur]

@ChrisRollins Yeah, I wouldn't trust anything C-based to handle null bytes properly in arbitrary data. That said, do you know of any other ASCII control characters beyond NUL actually being special for modern software? The null byte has the unfortunate history of being treated as special in almost anything C-based, due to its early design choice as a micro-optimization that made sense in those days, but as far as I know the other ~32 or so ASCII control characters are only special on command-line terminals and the like, for whom interpreting them is part of the intended design.

[Chris Rollins]

@mtraceur Well I think it just depends on the software. Chrome's JSON parser doesn't like other control chars either. But I don't know more than what i'm observing here. By the way, since I just finished a C class, I'd like to say that there's no reason software compiled with C should inherently have problems with null bytes in binary data. It would if the the programmer made a mistake and used the cstring functions (ie. strcmp, strcpy, strlen, etc) on binary data but that's a huge mistake because binary data is never null terminated. Instead the size of the data must be known.

[mtraceur]

@ChrisRollins You're absolutely right. That said, for the boolean check "if the programmer made a mistake" my branch-prediction is strongly trained to expect a true result, especially with languages like C. Which is why, given no other information about a system other than "it was written in C", I would not trust it to handle null bytes - not because the language makes it impossible to handle them properly, but because most people writing C don't do it.

[Chris Rollins]

@mtraceur Well yeah you shouldn't expect mistake-free code, but in this particular case a program that uses cstring functions to process input data would probably just be broken on 100% of input data in the first place.

[mtraceur]

@ChrisRollins Has that been your experience? That code mistakenly written using C's string functions fails for most/arbitrary inputs? The C code design error I've most frequently seen relating to C code not handling null bytes properly has usually been the sort where arbitrary data inputs work fine unless they contain null bytes. We've probably been exposed to different C software. Anyway, it sounds like we agree: I don't expect mistake-free code, and using C string functions on binary data is a common enough C mistake that I automatically suspect C code of making it until I've checked it.

[mtraceur]

I think I see the problem in my initial reply: "wouldn't trust" can be read as "could never be trusted" - I meant "trust" in the sense of feeling comfortable in expecting an outcome without being able to verify that the outcome is assured. I can and do trust C code that I've written/audited/tested for handling null bytes to continue to do so. I just meant that given unknown C code, I'm more weary of it mishandling null bytes than unknown code written in languages that don't treat null bytes a special in their language/library design.

[jjxtra]

While the json spec allows any char, I would suggest only to use leading _ or [A-Z], and then after the first char any combination of [A-Z], [a-z], [0-9] and _.

[Joe Elia]

This should be the best answer

[c-an]

Chinese or Arabic characters are fine for key?

[iMe]

I don't even know when I +1'ed this, but years later, I still approve 😎.

[Darren Ringer]

I found an interesting example of a forbidden key string on Oracle's Netsuite (SuiteScript, which is I believe JavaScript running on some version of the Rhino Engine, or some proprietary derivative thereof). I tried making a key "<none>" and try as I might, it would never come back with hasOwnProperty and it would never look up successfully. In fact at one point I had printed the object and it showed two identical keys of "<none>". When I tried to just make a simple list and use indexOf it didn't find "<none>" either.

[dolmen]

@JonLuzader Solution: testObject["1tile"]["sub-field"]