I can't figure out why in an @RemoteAction method you would want to JSON.serialize the object being returned? I see this in a lot of code and I'm trying to understand the reasoning. I thought @RemoteAction automatically serialized it for you. In fact when doing this it appears you must decode using htmlDecode since it's double encoded, once by Javascript Remoting and again by JSON.serialize method.

I trying to understand from an application design perspective the benefit of doing JSON.serialize and returning a String versus just returning the object/class when using JavaScript Remoteing.

Why do this:

public static List<User> searchUsersByName(String searchText) {
    return ChatterUIPeopleService.searchUsersByName(searchText);

Versus doing this:

public static String searchUsersByName(String searchText) {
    return JSON.serialize(ChatterUIPeopleService.searchUsersByName(searchText));

2 Answers 2


Since you're not required to do this, I believe people just do it because they don't know any better. They think "I'm calling this from Javascript, I better return JSON, so I need to serialize it." It's just one of many options that generate additional work, like returning String.valueOf(123) and sending it to a method that just does Integer.valueOf('123')

  • 3
    While there's plenty of reasons to use JSON.serialize, this is one of those times where that's completely unnecessary. The response received by JavaScript will naturally be a JSON object if it is not a primitive.
    – sfdcfox
    Jul 5, 2013 at 13:47
  • It appears that the response of JSON.serialize includes attributes (type and URL) that I don't see in the response of a JS Remote action. Does that sound correct and would that be the reason to use JSON.serialize? { "attributes" : { "type" : "Account", "url" : "/services/data/v24.0/sobjects/Account/001d000000Ard7uAAB" } Jul 8, 2013 at 16:03
  • 1
    @ChristianAnderson. You don't see those in JS Remoting because it knows the types its working with, as it discovers these by inspecting the method parameters. I believe you have a good answer here, what do you think? :) Jul 25, 2013 at 11:24
  • Worked perfectly for me :) Aug 30, 2017 at 7:31

If you're just loading data inside of the page I would strongly recommend not to use JSON.serialize. Especially for data intensive operations the payload is much bigger. As I'm a big fan of JSRemoting let me shortly list the advantages:

  • no attribute property, meaning no type and even better no url (reduced payload)
  • no escape characters for nested json (reduced payload)
  • doesn't count against API calls (cool if you use remoting for HTTP-proxying)
  • much json heap-size friendlier (yes the json.serializer has it's own heap size limitation)
  • real js date objects (easier to handle than iso date format!)
  • increases robustness towards governor limits (remoting response can be handled!)
  • and my personal favorite: referencing of recurring elements(!!), that means that e.g. sobjects in the json structure that occur more than once are only referenced in later occurences (check the actual transport JSON payload if you don't believe me and watch out for "serId" and "serRefId" properties) This can save an incredible amount of text and it's completely transparent for the developer as the references are resolved in the resulting js object.

Personally I think that JSRemoting is currently on of the most important and versatile features for the development of modern web applications on the force.com platform.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .