SPFx: Check if User is an Admin or an Owner is SharePoint

In this post: Introduction · Understanding SharePoint User Roles · Checking If a User Is an Admin in an SPFx WebPart · Checking in an Application Customizer · Alternative: Checking Site Owners Group Membership · The simpler check you probably want first · Pros and Cons of Different Approaches · Related reading

Introduction

When working with SharePoint Framework (SPFx), there are times when you need to determine whether a user has administrative privileges. This is especially useful in scenarios where certain UI elements or functionality should only be accessible to administrators. This post covers checking if a user is an admin using the site context in both an SPFx WebPart and an Application Customizer.

Understanding SharePoint User Roles

SharePoint provides different permission levels, and administrative privileges can vary based on context:

Site Collection Administrators: users with full control over the entire site collection.
Owners: users with full control over a specific site.
Tenant Administrators: users managing SharePoint at the tenant level.

Using SPFx, we can check user permissions via PageContext and Microsoft Graph APIs.

Checking If a User Is an Admin in an SPFx WebPart

SPFx provides this.context.pageContext.web to access the current web’s properties. One way to check for admin-level access is calling the effectiveBasePermissions REST endpoint and checking a specific permission bit:

import { BaseClientSideWebPart } from '@microsoft/sp-webpart-base';
import { SPHttpClient, SPHttpClientResponse } from '@microsoft/sp-http';

export default class AdminCheckWebPart extends BaseClientSideWebPart<{}> {

  private async checkIfUserIsAdmin(): Promise<boolean> {
    const webUrl = this.context.pageContext.web.absoluteUrl;
    const apiUrl = `${webUrl}/_api/web/effectiveBasePermissions`;

    const response: SPHttpClientResponse = await this.context.spHttpClient.get(apiUrl, SPHttpClient.configurations.v1);
    const data = await response.json();

    // ManageWeb permission bit, in the High part of the permission mask
    const manageWeb = 0x40000000;
    return (data.High & manageWeb) === manageWeb;
  }

  public async render(): Promise<void> {
    const isAdmin = await this.checkIfUserIsAdmin();
    this.domElement.innerHTML = `<h3>${isAdmin ? 'You are an Admin!' : 'You are NOT an Admin.'}</h3>`;
  }
}

Worth being precise about what this actually checks: 0x40000000 in the High mask is the ManageWeb permission bit specifically, not a literal “full control” flag — SharePoint’s real FullMask requires every bit set across both the High and Low 32-bit masks, which is a more involved bitwise comparison than a single-bit check. ManageWeb is a reasonable practical proxy (it’s the permission that actually grants site administration capability), but it’s answering “can this user manage the web” rather than the more absolute “does this user have every possible permission” — worth knowing the difference if the two ever need to be distinguished.

Checking If a User Is an Admin in an Application Customizer

An Application Customizer can be used when you need to check admin status across every page of a SharePoint site, rather than just one web part’s rendering:

import { BaseApplicationCustomizer } from '@microsoft/sp-application-base';
import { SPHttpClient, SPHttpClientResponse } from '@microsoft/sp-http';

export default class AdminCheckApplicationCustomizer extends BaseApplicationCustomizer<{}> {

  private async checkIfUserIsAdmin(): Promise<boolean> {
    const webUrl = this.context.pageContext.web.absoluteUrl;
    const apiUrl = `${webUrl}/_api/web/effectiveBasePermissions`;

    const response: SPHttpClientResponse = await this.context.spHttpClient.get(apiUrl, SPHttpClient.configurations.v1);
    const data = await response.json();

    const manageWeb = 0x40000000;
    return (data.High & manageWeb) === manageWeb;
  }

  public async onInit(): Promise<void> {
    const isAdmin = await this.checkIfUserIsAdmin();
    console.log(`User is ${isAdmin ? '' : 'not'} an admin.`);
  }
}

Runs across all pages of the site, which makes it useful for modifying site-wide UI based on admin status — global alerts, banners, or admin-only UI elements.

Alternative Approach: Checking Membership in Site Owners Group

Another way to check for admin rights is verifying whether the user is part of the “Owners” group:

const ownersGroupUrl = `${this.context.pageContext.web.absoluteUrl}/_api/web/AssociatedOwnerGroup/Users?$filter=Title eq '${this.context.pageContext.user.displayName}'`;
this.context.spHttpClient.get(ownersGroupUrl, SPHttpClient.configurations.v1)
  .then(response => response.json())
  .then(data => {
    console.log(data.value.length > 0 ? 'User is an Owner' : 'User is NOT an Owner');
});

The simpler check you probably want first

Every approach above involves an async REST call and manual response parsing. For the specific, narrower question of “is this user a Site Collection Administrator,” pageContext already has the answer built in, synchronously, with no network round-trip at all:

const isSiteAdmin = this.context.pageContext.legacyPageContext.isSiteAdmin;

The tradeoff is scope, not accuracy: isSiteAdmin answers specifically whether the user is a Site Collection Administrator — it won’t read true for a Site Owner who has full control of that one site without the Site Collection Administrator flag set, which is exactly the distinction the Understanding SharePoint User Roles section above draws between those two roles. If the actual requirement is “Site Collection Administrator specifically,” reach for isSiteAdmin first and skip the REST call entirely; the effectiveBasePermissions/ManageWeb approach above is what’s actually needed for the broader “does this user have site-owner-level control” question instead.

The comparison table below also lists a Microsoft Graph tenant-level check, worth showing rather than leaving abstract — it answers a genuinely different question again: whether the user holds a real SharePoint Administrator (or Global Administrator) directory role, which grants tenant-wide admin rights well beyond any single site:

const rolesUrl = `https://graph.microsoft.com/v1.0/me/transitiveMemberOf/microsoft.graph.directoryRole`;
const response = await this.context.msGraphClientFactory
  .getClient('3')
  .then(client => client.api(rolesUrl).get());

const isSharePointAdmin = response.value.some(
  (role: { displayName: string }) => role.displayName === 'SharePoint Administrator'
);

Filtering on microsoft.graph.directoryRole against transitiveMemberOf (rather than the non-transitive memberOf) is what makes this reliable — it catches role assignment through nested group membership, not just direct role assignment. This needs the Graph delegated permission scope for reading directory roles, granted through the SPFx web part’s manifest, which is the real setup cost the Cons column in the table below is pointing at.

For “is this user a Site Collection Administrator” specifically, pageContext.legacyPageContext.isSiteAdmin already has the answer — synchronously, no REST call needed.

Pros and Cons of Different Approaches

Approach	Pros	Cons
`isSiteAdmin` (pageContext)	Synchronous, no network call, simplest option	Only answers “Site Collection Administrator,” not Owner-level control
`effectiveBasePermissions` API	Checks actual granted permissions, not just a role flag	Requires understanding the bitwise permission mask; affected by permission inheritance
Owners Group Check	Works well for site-specific checks	Not useful for site collection admins who aren’t also in the Owners group
Microsoft Graph API (Tenant-Level Check)	Can check across all sites	Requires additional permissions

Actually, It’s Already In The SharePoint PageContext! — more properties already available on pageContext without an extra query, including isSiteAdmin.
All about SharePoint Permission Roles — background on what permission levels like Full Control actually grant.

Determining admin status in SPFx comes down to picking the right tool for what’s actually being asked — isSiteAdmin for a fast Site Collection Administrator check, effectiveBasePermissions when the real question is granted permissions rather than a role label, and an Application Customizer instead of a WebPart when the check needs to apply site-wide rather than to one page.

Questions or a scenario this doesn’t cover? Drop it in the comments.