JSON Naming Convention (snake_case, camelCase or PascalCase)

Is there a standard on JSON naming?
I see most examples using all lower case separated by underscore, aka snake_case, but can it be used PascalCase or camelCase as well?

In this document Google JSON Style Guide (recommendations for building JSON APIs at Google),

It recommends that:

1. Property names must be camelCased, ASCII strings.

2. The first character must be a letter, an underscore (_), or a dollar sign ($).

Example:

{
  "thisPropertyIsAnIdentifier": "identifier value"
}

My team consistently follows this convention when building REST APIs. There are some reasons:

• First, the JSON convention should be independent of the programming languages because we want our APIs to be consistent doesn't matter whether there are some APIs implemented using a camelCase language (e.g. Java), some others using snake_case language (e.g. Python).
• Also, most of our clients are webapp so camelCase is preferred
• If the client prefers snake_case, it still can easily convert data between snake_case and camelCase (with the help of libraries)

But I agree that if all the applications use the same type of language (e.g. snake_case), the JSON convention should also follow.

There is no SINGLE standard, but I have seen 3 styles you mention ("Pascal/Microsoft", "Java" (camelCase) and "C" (underscores, snake_case)) -- as well as at least one more, kebab-case like longer-name).

It mostly seems to depend on what background developers of the service in question had; those with c/c++ background (or languages that adopt similar naming, which includes many scripting languages, ruby etc) often choose underscore variant; and rest similarly (Java vs .NET). Jackson library that was mentioned, for example, assumes Java bean naming convention (camelCase)

UPDATE: my definition of "standard" is a SINGLE convention. So while one could claim "yes, there are many standards", to me there are multiple Naming Conventions, none of which is "The" standard overall. One of them could be considered the standard for specific platform, but given that JSON is used for interoperability between platforms that may or may not make much sense.

ECMA-404

> The JSON syntax does not impose any restrictions on the strings used as names,...

There is no standard naming of keys in JSON and that camelCase or snake_case should work fine.

TL;DR

Here is a rule-of-a-thumb which I think most of the developers use.

Technology stack	Naming convention	Reason/guide
Python » JSON » Python	snake_case	Unanimous
Python » JSON » PHP	snake_case	Unanimous
Python » JSON » Java	snake_case or camelCase	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
Python » JSON » back‑end JavaScript	snake_case or camelCase	Lean on where the business logic resides.
Python » JSON » front‑end JavaScript	snake_case	Screw the front-end anyway
Python » JSON » you do not know	snake_case	Screw the parser anyway
PHP » JSON » Python	snake_case	Unanimous
PHP » JSON » PHP	snake_case	Unanimous
PHP » JSON » Java	snake_case or camelCase	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
PHP » JSON » back‑end JavaScript	snake_case or camelCase	Lean on where the business logic resides.
PHP » JSON » front‑end JavaScript	snake_case	Screw the front-end anyway
PHP » JSON » you do not know	snake_case	Screw the parser anyway
Java » JSON » Python	camelCase or snake_case	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
Java » JSON » PHP	camelCase or snake_case	Lean on where the business logic resides. Take advantage of the extrinsic style of Java.
Java » JSON » Java	camelCase	Unanimous
Java » JSON » JavaScript	camelCase	Unanimous
Java » JSON » you do not know	camelCase	Screw the parser anyway
back‑end JavaScript » JSON » Python	camelCase or snake_case	Lean on where the business logic resides.
front‑end JavaScript » JSON » Python	snake_case	Screw the front-end anyway
back‑end JavaScript » JSON » PHP	camelCase or snake_case	Lean on where the business logic resides.
front‑end JavaScript » JSON » PHP	snake_case	Screw the front-end anyway
JavaScript » JSON » Java	camelCase	Unanimous
JavaScript » JSON » JavaScript	camelCase	Original
JavaScript » JSON » you do not know	camelCase	Screw the parser anyway

Driving factors

Imposing a naming convention is very confusing because JSON alone does not impose a standard. However, this can easily be figured out if you break it down into components.

JSON generator

Programming language	Naming convention
Python	snake_case
PHP	snake_case
Java	camelCase
JavaScript	camelCase

JSON parser

Programming language	Naming convention
Python	snake_case
PHP	snake_case
Java	camelCase
JavaScript	camelCase

Bulk of business logic

You have to decide which side has the heavier business logic, is it the JSON generator side or the JSON parser side?

Natural belongingness

Programming language	Natural belongingness
Python	intrinsic
PHP	intrinsic
Java	extrinsic
JavaScript	intrinsic

Intrinsic - Programming language where JSON is accessed naturally similar to accessing native objects and arrays.

Extrinsic - Programming language where JSON is accessed differently than accessing native objects and arrays. Below is an example of Java's com.google.gson package:

/**
 * Using a method to access a property instead of using the standard 'dot.syntax'
 */
JsonElement.getAsString("snake_cased_key");

Some actual implementations

• Google Maps JavaScript API - camelCased
• Facebook JavaScript API - snake_cased
• Amazon Web Services - snake_cased & camelCased
• Twitter API - snake_cased
• JSON-LD - camelCased

Conclusions

Choosing the right JSON naming convention for your JSON implementation depends on your technology stack. There are cases where you can use snake_case, camelCase, or any other naming convention.

Another thing to consider is the weight to be put on the JSON-generator vs the JSON-parser and/or the front-end JavaScript. In general, more weight should be put on business logic side.

Also, if the JSON-parser side is unknown then you can declare what ever can work for you.

Notably for me on NodeJS, if I'm working with databases and my field names are underscore separated, I also use them in the struct keys.

This is because db fields have a lot of acronyms/abbreviations so something like appSNSInterfaceRRTest looks a bit messy but app_sns_interface_rr_test is nicer.

In Javascript variables are all camelCase and class names (constructors) are ProperCase, so you'd see something like

var devTask = {
		task_id: 120,
		store_id: 2118,
		task_name: 'generalLedger'
	};

or

generalLedgerTask = new GeneralLedgerTask( devTask );

And of course in JSON keys/strings are wrapped in double quotes, but then you just use the JSON.stringify and pass in JS objects, so don't need to worry about that.

I struggled with this a bit until I found this happy medium between JSON and JS naming conventions.

Seems that there's enough variation that people go out of their way to allow conversion from all conventions to others: http://www.cowtowncoder.com/blog/archives/cat_json.html

Notably, the mentioned Jackson JSON parser prefers bean_naming.

I think that there isn't a official naming convention to JSON, but you can follow some industry leaders to see how it is working.

Google, which is one of the biggest IT company of the world, has a JSON style guide: https://google.github.io/styleguide/jsoncstyleguide.xml

Taking advantage, you can find other styles guide, which Google defines, here: https://github.com/google/styleguide

As others have stated there is no standard so you should choose one yourself. Here are a couple of things to consider when doing so:

1. If you are using JavaScript to consume JSON then using the same naming convention for properties in both will provide visual consistency and possibly some opportunities for cleaner code re-use.

2. A small reason to avoid kebab-case is that the hyphens may clash visually with - characters that appear in values.

   {
     "bank-balance": -10
   }