Using SPServices to Get the Display Names for a SharePoint List’s Content Types – Follow Up

A couple of weeks ago I got a question from my pal Tasha Scott (@TashasEv) about how to find the DisplayName of a Content Type on a NewForm. At the end of the code in that post, I had the comment:

//... do something with the Content Type Name ...

Well, it turned out that the “do something” that Tasha wanted was to display that name in the page title to give the user a better handle on what they were actually creating. This is a powerful idea, especially if you have Content Types that have similar metadata structures so that the user can remember what they are up to.

This is a great example of what I talk about in my Enhancing the User Experience with jQuery sessions at conferences. It’s not always about the big, flashy stuff. In this case, a simple change to the page title gives the user better context for what they are doing (think about the case where they go to the NewForm and then have to take a long phone call) and improves their experience with SharePoint. Small investments like this on frequently used pages can provide ridiculously good benefit for the small outlays.

So, in my silly test list NewForm, we go from…


Tasha posted the code that she ended up using on my prior post, but I decided to clean it up a little bit and post it here. You might even consider adding this to your master page if you are using a lot of Content Types in your lists, which means, of course, that you are using SharePoint well.

$(document).ready(function() {

  // The SPGetQueryString function parses the Query String values out into an array
  var queryStringVals = $().SPServices.SPGetQueryString();
  // This grabs the value of the ContentTypeId Query String parameter
  var contentTypeIdValue = queryStringVals["ContentTypeId"];
  // Define a variable to hold the name of the Content Type
  var contentTypeName = "";

  // Get the list's Content Types
    // See the MSDN SDK at for details on this operation
    operation: "GetListContentTypes",
    // The SPListNameFromUrl function gets the list name for the current context based on the URL
    listName: $().SPServices.SPListNameFromUrl(),
    // We'll do this asynchronously
    async: false,
    completefunc: function (xData, Status) {
      // Find the Content Type with the matching ID
      $(xData.responseXML).find("ContentType[ID='" + contentTypeIdValue + "']").each(function() {
        // the name in our variable...
        contentTypeName = $(this).attr("Name");
  // Add the Content Type name to the page title
  var currentTitle = $(" h2").html();
  $(" h2").html(currentTitle.replace(":", ": " + contentTypeName + " - "));


  1. Again, Marc, well done and I am glad you can see the value in what I was attempting to accomplish! You hit the nail on the head with the usage case- especially in lists where perhaps you have a decent number of content types applied.

    Thanks again! Hopefully I’ll be seeing you soon!

  2. if you have two content types attached to the doclib/lists this dosent work the first time, the content type retuns undefined, but if you switch between the content types it does work

    • I don’t think that should be the case. If the ContentTypeID is on the Query String, it works. You may have arrived at the NewForm through a route where the Content Type hasn’t been selected yet.

      You can also wrap the update to the page in an if statement so that you only do the work if there’s a ContentTypeId:

      if(qsContentTypeId !== undefined) {
        // Get the name from the list and update the page title


  3. I cant really understand how this works.
    even after removing all the content types and just having one, i cant find the content type id in the query string in editform.aspx of the document library.
    but if i try to modify the properties then i see the content type id in the query string. This is weird.
    to asnwer the page i driving from is the regular OOTB page from all documents view, add documnet

    • Note that this post is about the NewForm, which has the ContentTypeId on the query string, depending on the path the user has taken. The EditForm doesn’t need the ContentTypeId because the Content Type has already been set.


  4. ah, finally made it work but lost ball in the high weeds :)
    i was working with doc lib so there isnt newform. i made a common js libs to call out the js on the 14 hive. Thanks for your reply mark . appreciate it


Have a thought or opinion?