The Difference Between Default & Custom Master Pages

If you have ever right clicked a master page in SharePoint Designer, you probably noticed that you can set a master page as the default master page as well as the custom master page. When you create a new SharePoint 2010 site, by default, you will notice that the v4.master master page, found in the /_catalogs/masterpage directory, has already been set as your default and custom master page. But what is the difference?
There are two primary differences.
First, the kicker in my opinion, the custom master page is the master page that pages that inherit from the PublishingLayoutPage class use. You can read more about this in an article I wrote a little while ago (Difference Between PublishingLayoutPage and WebPartPage Classes).  This is rather important in Publishing sites, or Foundation sites with Publishing enabled. Let me repeat this because it spins many developers for a loop every time it seems. If you have a publishing site and you create a new publishing page, (a page that goes into the /pages/ directory), any layout page that this page uses will always use the master page that is set as the custom master page. Even if you attempt to change the page declaration of the layout page, the page will still end up using the custom master page. The best way around this is to create your own class that inherits from PublishingLayoutPage that your layout page can then use. This is not a trivial task though and is beyond the scope of this post.
Second, which is more obvious, a default and custom master page allows you to easily create and use two master pages throughout your SharePoint site collection and/or each sub site. You could create your default master page that some pages will use and then create a second, custom master page that other pages will use. Obvious enough.
As an example, related to our first discussion of custom master pages and Foundation sites with Publishing features enabled. You could create a site with pages in the sitepages directory that utilize the default master page, while at the same time having pages in the Pages directory (that utilize layout pages) that will use the custom master page. This provides you the ability to easily have two different styles in one site. Now the changes might be extreme or just slight, but would be best handled in the master page.
A second example would be where you want to simply have two different types of branded pages in your SharePoint site that be easily switched to a different master page as needed. What I mean is that if you have Branding A and Branding B, A being for top level pages and B being for lower level pages, and each needs say a slightly different header and quick launch bar layout, you could set A pages with the default master page and B pages with the custom master page. Now if you ever had to change Branding A pages to use a new default master page, you could just set your new master page as your default master page and all Branding A pages would automatically begin using the new default master page. This would be a lot quicker than if you had hard coded the master page file in each of Branding A pages Page declaration.
Finally as a quick reference, to set a page to use the default master page, your page declaration would look similar to

<%@ Page Language="C#" Inherits="Microsoft.SharePoint.WebPartPages.WikiEditPage" MasterPageFile="~masterurl/default.master" meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document"   %>

While if you wanted to set a page to use your custom masterpage, your page declaration would look similar to

<%@ Page Language="C#" Inherits="Microsoft.SharePoint.WebPartPages.WikiEditPage" MasterPageFile="~masterurl/custom.master" meta:webpartpageexpansion="full" meta:progid="SharePoint.WebPartPage.Document"   %>

I hope this has been a help. Have you found other reasons to have a default and custom master page? Please tell us.

3 thoughts on “The Difference Between Default & Custom Master Pages

  1. June 7, 2012

    Being a SharePoint noob this helped me tremendously. Just yesterday I was struggling with what to do about my master page displaying incorrectly for pages not created as a publishing page. Problem solved.

  2. Shiva October 16, 2012

    Nice article, helpful to all branding pros

  3. Andrew February 17, 2016

    Clear article which helped me, but you should fix the markup that you are quoting.
    <%@ Page Language="C#" Inherits="Microsoft.SharePoint.WebPartPages.WikiEditPage" is truncated for me, I am using Chrome.

Leave a Comment

Your email address will not be published. Required fields are marked *

Enter Code *

Filed Under


The Microsoft Viva modules are revolutionary tools used to aid one's work stability and improve their digital workspace experience. Find out more by tuning into to Eric Overfield's "The State of Microsoft Viva & The Digital Workspace" PixelMill Webinar!

Not sure what an Employee Experience Platform is and how Microsoft Viva fits into that? Then check out the PixelMill Webinar "The state of Microsoft Viva and The Digital Workspace" by Eric Overfield!

Get excited for our next episode of the #PixelMillWebinars! In this session:
-Power Platform 101:Power Automate, Power Apps, Power Virtual Agents, Power Pages & Power BI  
-Power Platform in action on an intranet  
-Power Platform adoption best practices

Imagine having all the tools and resources you need to be successful in just one place! Eric Overfield digs deeper into the details of Microsoft Viva and how Teams + Viva can make that dream a reality. Watch the latest PixelMill Webinar to learn more!

Get excited for our next episode of the #PixelMillWebinars! Our CPO, Microsoft MVP & Regional Director Eric Overfield breaks down:
-Each of the 9 GA Viva Modules
-How the modules integrate
-Successful practices when rolling out Viva in your organization

Subscribe to PixelMill's

* indicates required

Let's Talk Digital
Workspaces Today

Get In Touch