I see a lot of questions revolving around accessing JSON keys that use hyphens (kebab-case), but now I find myself wondering should I just stick to camelCase or snake_case in my keys. I know hyphens also can create complicated mappings when ported between languages. I've seen some JSON deserialize libraries convert those keys to a camelCase style.


var something = {
  "some-value": 'thing'


var something = {
  "someValue": 'thing',
  "some_other_value": 'thing_two'
  • 4
    REST has nothing to say about payload formats. – Eric Stein May 28 '16 at 17:24
  • 2
    Why do you use kebab-case in JSON? People usually use camelCase for JSON because it's always good practice to follow the naming conventions of the programming environment and it's standard practice to use camelCase for variables in JavaScript. Though I'm going by the assumption that you're using JSON to communicate with JavaScript. – Alternatex May 28 '16 at 17:41
  • 1
    I see the question is tagged with javascript, but the question itself seems to be about an API between different languages / libraries. If you are concerned with javascript, note that dot notation doesn't work with hyphens. – Izkata May 29 '16 at 13:27
  • 5
    It is not really a bad practice, since JSON is language independent and therefore shouldn't be constrained by the syntax of any particular language. That said, it makes sense to use only alphanumerical characters, since this can map directly to identifiers in all mainstream languages, so this will just lead to the least amount of mapping trouble. – JacquesB May 29 '16 at 19:07
  • 1
    @Alternatex: +1 for "kebab-case" :-) – gnasher729 Nov 3 '16 at 20:40

You can use anything as JSON keys, as long as it is valid UTF-8, doesn't contain zero code points, and it would be useful if you could represent the key as a string in the programming language of your choice. I might recommend not to use different Unicode representations of the same string (for example "Ä" written as one or two code points).

Reading some comments: It seems some people try to create classes with instance variables that match the keys in JSON dictionaries. Which of course doesn't work if your key is "some-value" unless you write COBOL. I think this is misguided. I have model classes which are designed the way I want them. JSON is just used to fill the model classes. I'll take whatever the server guys decided to use for the keys and put it into my model objects.

  • 1
    urg, you beg the question of how your consuming program accesses the json keys. Commonly this is done by parsing the json as an object. Using hypens or other characters which prevent this just makes life hard for your consumers – Ewan May 30 '16 at 22:44
  • And this is valid: {"❓":"✅"} – Vinicius Brasil May 17 '19 at 21:26
  • 1
    How do hyphens prevent anything? I get a dictionary, and a can use "some-key" as a key, I can even use "❓" as a key. – gnasher729 May 17 '19 at 23:16

There are plenty of JSON serialization systems that are more than capable of handling mapping between field names that aren't suitable for use in the language they integrate with. In most cases, they aren't hard to use, and require only a little bit of extra effort. In an ideal world, you wouldn't have to, but if your API already uses dashes, changing it would be cure worse than the disease. Also note that using dashes is the most common style in certain languages, most notably those based on LISP, so probably there's a silent minority of your API's consumers who are happy to see dashes rather than another format.

  • I will up vote this ASAP I found insight in it, Thank You. – Matt Oaxaca May 29 '16 at 17:21

After spending some time in the industry and working a few systems. I don't think there is a best practice or proper casing for JSON keys. The most important aspect of any formatting (casing/code-style/etc) is consistency and team adoption.

If the code base is fragmented and inconsistent, meet as a team and agree on a consistent style then police the formating collectively.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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