SharePoint Modern Pages Now Support Custom HTML — What This Changes for SPFx Developers

For years, the answer to "I want to add a custom banner/countdown/table/interactive element to a SharePoint page" was the same: build an SPFx web part. Even for simple requirements — a styled announcement box, a custom colour band, a JavaScript countdown timer — you needed Node.js, npm, Gulp (or webpack), TypeScript, a development certificate, and a deployment to the app catalog. The overhead was enormous relative to the output.

Microsoft has changed that. Modern SharePoint pages now include a native HTML web part that accepts raw HTML, CSS, and JavaScript directly in the page canvas. No build pipeline. No deployment. No app catalog. You write HTML, press save, and it works.

This post covers exactly what changed, how the HTML web part works, what its security model looks like, what it genuinely can and cannot do, and — critically — what this means for when you still need to build an SPFx web part.

What Exactly Changed

The old "Embed" web part on modern pages accepted iframes and limited oEmbed URLs, but blocked raw HTML/CSS/JS execution entirely. Microsoft's trust model for modern pages prohibited script execution — it was a deliberate security boundary that replaced the classic Script Editor web part that SharePoint admins had long restricted.

The new HTML web part (appearing in the web part picker under "Media and Content") works differently:

• You get a code panel — syntax-highlighted, multi-line — that accepts a full HTML fragment with inline <style> and <script> blocks
• The fragment renders inside the page section at full width, with access to the page's CSS custom properties (your SharePoint theme colours)
• JavaScript executes — fetch(), querySelector(), DOM manipulation, event listeners — all work
• Microsoft Graph calls from JavaScript work if the user is authenticated (same-origin session cookie), without extra OAuth configuration for read-only scenarios
• The feature is governed by a tenant-level and site-level admin toggle, not on by default for all sites

How to Enable It

What You Can Build with It — Real Examples

Here's a real example: a styled announcement banner with a countdown timer and a dismiss button — the kind of thing that previously required a full SPFx web part project.

<style>
.sp-banner {
  background: linear-gradient(135deg, #003a8c 0%, #0078d4 100%);
  border-radius: 12px;
  padding: 28px 36px;
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 24px;
  flex-wrap: wrap;
}
.sp-banner h3 { color: #fff; margin: 0 0 6px; font-size: 1.15rem; }
.sp-banner p  { color: rgba(255,255,255,.7); margin: 0; font-size: .9rem; }
.sp-countdown { font-size: 2rem; font-weight: 800; color: #fff; white-space: nowrap; }
.sp-dismiss {
  background: rgba(255,255,255,.18); border: none;
  color: #fff; padding: 10px 20px; border-radius: 8px;
  cursor: pointer; font-weight: 600;
}
</style>

<div class="sp-banner" id="sp-ann">
  <div>
    <h3>📅 System Maintenance Window</h3>
    <p>Planned downtime: September 6, 2026 — 10:00 PM to 2:00 AM IST</p>
  </div>
  <div class="sp-countdown" id="sp-cd"></div>
  <button class="sp-dismiss" onclick="document.getElementById('sp-ann').style.display='none'">Dismiss</button>
</div>

<script>
const target = new Date('2026-09-06T22:00:00+05:30');
function tick() {
  const diff = target - Date.now();
  if (diff <= 0) { document.getElementById('sp-cd').textContent = 'Now'; return; }
  const d = Math.floor(diff / 86400000);
  const h = Math.floor((diff % 86400000) / 3600000);
  const m = Math.floor((diff % 3600000) / 60000);
  document.getElementById('sp-cd').textContent = `${d}d ${h}h ${m}m`;
}
tick(); setInterval(tick, 60000);
</script>

That's a live, dismiss-able announcement banner with a countdown — zero SPFx, zero npm, zero deployment. Paste it, publish, done.

Other real-world scenarios now solvable with the HTML web part

• Custom styled tables — HR policies, IT asset tables, rate cards with conditional row colours
• Accordion / FAQ sections — toggle-able panels built with <details> or JS, no framework needed
• Lightweight Graph API reads — fetch the current user's profile, display their manager, or pull a list of team members inline on the page
• Interactive forms that POST to Power Automate HTTP triggers — a quick feedback widget without a Power Apps canvas app
• Embedded SVG illustrations — diagrams, org chart snippets, icon grids
• Custom KPI tiles — fetch a number from a SharePoint list or an API, display it with a big styled number
• Colour-branded hero sections — full-width gradient banners with overlaid text and a CTA button, site-identity-matched

The Security Model — What Microsoft Did & Didn't Lock Down

This is the question every SharePoint admin will ask. Microsoft did not ship an open Script Editor with no guardrails. Here's the actual security model:

• Tenant + site double opt-in: Both the tenant-level and site-level toggles must be on. No toggle, no web part in the picker.
• Author-only edit: Only users with Edit or higher permissions on the page can insert or modify the HTML web part. Visitors see the rendered output only.
• Script runs as the viewing user: There is no service account or elevated context. fetch() calls run under the signed-in user's session. You cannot do anything the user couldn't do manually.
• No localStorage cross-site persistence: The script runs in the SharePoint page origin — same as any other page script — so localStorage is scoped to the SharePoint tenant domain, not a separate sandbox.
• No eval() of externally fetched strings: The CSP on modern SharePoint pages blocks eval() and new Function() with remote content. You can't pull a remote script and eval it.
• External script src loading is blocked by CSP: <script src="https://cdn.external.com/..."> is blocked. Inline scripts work; external CDN scripts do not (unless they are on Microsoft's CSP allowlist, which includes certain Microsoft CDNs).
• Audit logging: HTML web part additions and modifications are captured in the SharePoint Unified Audit Log — same as any page edit.

HTML Web Part vs SPFx — When to Use Which

This is the practical question. The HTML web part is not a replacement for SPFx — it's a replacement for cases where SPFx was massively over-engineered. Here's the honest breakdown:

The Real Impact for SharePoint Teams

For enterprise SharePoint teams, this changes the tier model for intranet requests. Previously every custom requirement — even trivial ones — required a developer with an SPFx environment. Now:

• Tier 1 (HTML web part): Display-only customisations, simple interactivity, one-site requirements. Power users and page authors can handle these.
• Tier 2 (SPFx web part): Complex apps, write operations, multi-site reuse, Viva/Teams integration. Still needs a developer.
• Tier 3 (SPFx + Graph + Backend): Full enterprise apps with auth flows, custom APIs, and ALM. Always was and still is developer territory.

This means development teams can spend their time on higher-value SPFx work — the complex, reusable solutions that genuinely require a build pipeline — while page authors handle the long tail of simple intranet requests themselves.

Limitations to Know Before You Start

• No external CDN scripts: SharePoint's CSP blocks <script src> from unapproved external origins. All JS must be inline or hosted on SharePoint itself (e.g. in a document library or Site Assets).
• No eval(): Dynamically evaluating strings as code is blocked by CSP. Stick to standard DOM APIs.
• No persistent server-side state: The web part has no server-side execution. Everything runs in the browser on the user's session.
• No property pane: Unlike SPFx, there's no built-in configuration UI. If you need an instance-configurable web part (different settings per page), SPFx is still the answer.
• Editor access restriction: Only users with Edit permission can modify the HTML. This is by design but means page authors with Contribute (not Edit) can't modify it.
• Not available in Teams/Viva Connections: Pages surfaced in Teams via Viva Connections render differently; HTML web parts may not render in all Teams contexts.
• Rollout is staged: As of August 2026 the feature is in Targeted Release / First Release rings. Standard Release tenants will receive it in the coming weeks. Check your release ring in the Microsoft 365 Admin Center.

Full Feature Comparison

Getting Your Team Started

If you're a SharePoint admin reading this, here's a pragmatic rollout approach:

1. Enable on intranet/communications sites first — where page authors are trusted and content is display-oriented. Hold off on team sites with sensitive data until you've assessed author trustworthiness.
2. Create a snippet library — a SharePoint list or Wiki page of approved HTML snippets your authors can copy and paste. Banners, KPI tiles, countdown timers, FAQ accordions. Curated snippets reduce the risk of poorly written code and save authors time.
3. Update your governance policy — add the HTML web part to your site governance documentation. Specify which sites it's enabled on, who can use it, and what types of HTML are and aren't acceptable.
4. Train page authors — a 45-minute session covering the basics of HTML/CSS, how to use the web part, and what the guardrails are. Most modern SharePoint power users can handle simple HTML if given a starting template.

Summary

The SharePoint HTML web part is a genuine shift in how modern pages work. For the first time since the Script Editor web part was deprecated, page authors can run custom HTML, CSS, and JavaScript on a SharePoint page without a developer and a build pipeline. That's a big deal.

It won't replace SPFx — it was never designed to. SPFx is still the right tool for complex apps, reusable components, Viva Connections, and anything that requires proper state management or write operations. But the huge category of simple intranet customisations that were previously over-engineered into SPFx projects? Most of those are now HTML web part territory.

Enable it. Curate some starter snippets. Train your page authors. And redirect your SPFx capacity toward the solutions that actually warrant it.