SharePoint HTML pages or SPFx apps? What each approach can do and where it stops

We have mentioned SharePoint HTML pages several times in our monthly roundups — among other things as a new feature that is switched on and cannot be turned off for the whole tenant. Now they are reaching general availability, and with them comes a question we hear from customers more and more often: if Copilot can write a good-looking interactive page with charts in a minute, why would we still need apps?

It is a fair question. HTML pages really can do things that used to need a developer. But they also have limits that are not obvious at first glance — and some of them only show up six months later, when there are fifty pages and each one looks slightly different. This article compares the two approaches: HTML pages on one side, and apps built on the SharePoint Framework (SPFx) — the same foundation our EasyPortal 365 apps are built on — on the other.

What SharePoint HTML pages are

Microsoft announced the feature on 25 September 2026 (MC1479517). Preview started in October; general availability rolls out from mid-November to late December 2026. In short:

• How a page is created: via + New → HTML page, with the floating Copilot button on a site, or by uploading a finished .html file (or a whole folder) to the Site Pages library.
• Where it lives: in the Site Pages library alongside regular modern pages. Site permissions, retention, drafts and publishing, approvals, scheduling and analytics all apply. It is shown with the site’s header, navigation and footer.
• How it renders: the content runs in a sandboxed iframe with Content Security Policy rules. The page is isolated from the rest of SharePoint.
• Licensing: a Microsoft 365 Copilot licence is needed only to create and edit with Copilot. Anyone with the right permissions can upload HTML, edit text, publish and read the page — without a licence.
• Administration: the feature is on by default and can only be turned off site by site — details in the next section.

When you will get it and how to turn it off

Not everyone gets it at once. Microsoft is rolling the feature out tenant by tenant. Since October it has been available to organisations in the Frontier programme and on targeted release; everyone else gets it with general availability — according to the announcement from mid-November to late December 2026, and according to a later reply from Microsoft in the discussion the rollout may run into early 2027. To see whether your tenant already has it, check any site: in the Site Pages library, File types gains an Allow HTML files switch and uploading offers Upload HTML page. (Microsoft ties creating via + New → HTML page to a Copilot licence, so without one you can’t rely on that menu item.)

Once your tenant gets it, it is on for every site. Nobody has to enable it. Anyone allowed to edit pages on a site can then upload and publish HTML. Only users with a Copilot licence can create pages with Copilot.

It can only be turned off site by site. On each site separately, the site owner opens the Site Pages library, selects File types and turns off Allow HTML files. This removes HTML uploads and the + New menu item. The feature cannot be turned off or restricted for the whole tenant, and Microsoft said in the discussion that this will stay so for the time being. Administrators can check the state of individual sites with PnP PowerShell (Get-PnPFeature, feature HtmlPages). Microsoft does not describe a way to turn it off for many sites at once.

The switch doesn’t hold yet. Independent tests after launch showed that on a site with the switch off, Copilot kept creating HTML pages. One user in the discussion also reported that uploading and moving files still worked. Microsoft replied that it is investigating the Copilot case and that uploads and moves should be blocked when the switch is off. Until that is fixed, the site switch is not a reliable boundary.

What works inside an HTML page — and what doesn’t

This is the heart of the comparison. The sandbox is good for security, but it also defines exactly what a page can do. Based on Microsoft’s documentation and detailed community testing:

Works	Doesn’t work
your own JavaScript inside the file	scripts and styles from other addresses (CDNs, <link> to CSS, Google Fonts)
five libraries from Microsoft’s CDN: Chart.js, Mermaid, React, Fluent UI, Babylon	any API call — fetch, SharePoint REST, Microsoft Graph
animation, Canvas, SVG, dark mode via CSS	cookies, localStorage, IndexedDB — the page remembers nothing
reading a file the user picks on their own computer	submitting a form, downloading a file, a print button (printing from the browser works)
read-only live data from SharePoint lists, Excel and CSV	writing anything anywhere
links within the tenant, external links to allowed domains	mailto:, tel:, embedded video, frames (YouTube, Stream)
images from your own tenant or embedded in the file	images from other websites, SharePoint web parts

The most important row is the one about data. Live data works by the page declaring its sources up front (a list, an Excel workbook, a CSV), and SharePoint loading them when the page opens and handing them over. The page itself reaches nowhere. It is a read-only snapshot: anything that changes in the list while the user has the page open only appears after a refresh. Writing anything back — approving a request, adding an item, saving a form — is something an HTML page cannot do.

Two details from the tests are worth knowing. First, a list sends all of its columns to the browser, including those the page doesn’t display — in one test 85 columns instead of the dozen or so actually used. Second, SharePoint search indexes only text written directly in the HTML file. Anything a script renders — charts, tables, numbers from live data — is invisible to search.

What a SharePoint Framework app is

The SharePoint Framework is the model Microsoft recommends for extending SharePoint, Teams and Viva Connections. An SPFx app is a packaged program (web parts, extensions) that an administrator approves in the app catalogue, and which then runs on SharePoint pages, as a tab in Teams, in Viva Connections and now also as components inside Copilot.

The key difference from HTML pages: an SPFx app runs in the context of the signed-in user and has clients that handle sign-in to SharePoint, Microsoft Graph and other APIs protected by Microsoft Entra ID on the user’s behalf. It can therefore both read and write — always only where the user has permission, and to APIs outside SharePoint only with permissions an administrator approves.

The other side of the coin: Copilot won’t write an SPFx app in a minute. It needs a developer, a build with Node.js and TypeScript, testing, deployment to the app catalogue and version management. And because it doesn’t run in a sandbox but directly in the page, the administrator decides on trust by approving the app.

Point-by-point comparison

	HTML page	SPFx app
Who builds it	anyone allowed to edit pages; with Copilot, even without knowing HTML	a developer
How long it takes	minutes to hours	days to weeks
IT approval	none (and it can’t be enforced at tenant level)	the administrator approves the app and its API permissions
Data	read-only, a snapshot at open; lists, Excel, CSV	read and write; SharePoint, Graph, custom APIs
Who the user is	the page doesn’t know	the app knows the user, their roles and groups
Memory	none — every visit starts from scratch	lists, settings, history, work in progress
Look and feel	whatever is in the file; site theme changes don’t carry over	follows the theme and shared components
Updates	each page separately	one release takes effect everywhere the app runs
Teams and mobile	yes in the Teams desktop app; not yet in the Teams and SharePoint mobile apps	web parts in Teams, Viva Connections, mobile view
Search	only the file’s static text	depends on where the app stores data (lists and libraries are indexed)
Security	sandbox — the page can’t call APIs, submit forms or store anything	full access within the user’s permissions; trust via administrator approval
Licensing	Copilot only for creating with Copilot	depends on the app vendor

Where HTML pages shine

It would be a mistake to underestimate them. For many scenarios they are a better choice than an app or even a classic modern page:

• Speed and design freedom. An onboarding timeline for a new colleague, a project overview with charts, a visual brand guide, an event microsite — all of this can be built in an afternoon and look exactly as intended, without being limited to sections and web parts.
• Interactive tools. A calculator, a checklist, an interactive process diagram or a CSV check before an import. Everything runs in the browser and nothing leaves the user’s computer.
• Dashboards over data already in SharePoint. A chart from a list or from Excel that refreshes every time it is opened, without Power BI and without a developer.
• Recycling existing HTML. Report exports, static pages from old systems, output from other tools — upload and done.
• Secure by design. Because the page can’t call APIs or submit forms, the risk from badly written code is much lower than with the old Script Editors, which had no such limits.

Weaknesses: standardisation, maintenance and governance

This is what easily gets lost in the excitement about speed. None of these weaknesses is a bug — they follow directly from the fact that every HTML page is a separate, self-contained file.

Every page is an original. Copilot writes a page based on the prompt and on whatever it comes up with at the time. A second author on the next site gets different shades, different fonts, different spacing and a table that behaves differently. Modern pages stay consistent thanks to the theme and web parts, apps thanks to shared components. HTML pages have no such common foundation — consistency depends on each author individually.

The look freezes at creation. Colours and fonts are written into the file when it is created. When the organisation changes the site theme or its brand colours, existing HTML pages don’t change. Microsoft lists this as a known limitation “with no commitment” to address it. Uploaded HTML doesn’t get the corporate look automatically at all. After a rebrand, every page has to be edited by hand.

Code can’t be shared. Neither styles nor libraries can be loaded from a shared file — according to tests, a <link> to CSS in Site Assets doesn’t work, and everything has to be inside the file. Fixing a bug in a table used on thirty pages means fixing thirty files. With an app, one release is enough.

Accessibility isn’t guaranteed. Microsoft says pages created by Copilot automatically meet accessibility requirements — but uploaded HTML doesn’t. Checking headings, contrast, image descriptions and keyboard use stays with the author.

Maintenance after the author leaves. Anyone who knows the editor can edit a modern page. An HTML page with scripts can only be edited safely by someone who understands the code, or by Copilot — and only for users with a licence. Tests also showed that editing a scripted page in the visual editor can break its scripts.

Missing what an intranet usually needs. An HTML page can’t be promoted to news, has no comments or reactions, can’t be turned into a template, has no audience targeting or multilingual versions, and doesn’t yet appear in the SharePoint and Teams mobile apps (Microsoft lists them as a “fast follow”).

Governance without a central switch. The feature is on, can’t be turned off at tenant level, and according to tests the site switch doesn’t yet stop Copilot. Anyone who wants oversight has to get it from rules and content review, not from a setting.

When to use which

An HTML page is the right choice when:

• it is about presentation, not working with data — content is read, not written,
• the page is one-off or short-lived — an event, a campaign, a project, onboarding,
• read-only data from a list, Excel or CSV is enough,
• design matters more than consistency with other pages,
• there will be a few pages, not hundreds.

An SPFx app is the right choice when:

• the user has to do something — fill in, approve, book, report, order,
• the app needs to know who the user is and show different things depending on their role,
• data is written or needs to be remembered between visits,
• the same function runs on many sites and must look and behave the same everywhere,
• you need Teams, mobile or a connection to Microsoft Graph (mail, calendar, profiles),
• the solution has to live long-term, be updated and have a clear owner.

A modern page remains the default for everyday intranet content — news, department pages, guides. It is consistent, anyone can edit it and it inherits the theme.

The approaches also don’t exclude each other. A sensible split: modern pages for content, apps for work, and HTML pages for things that mainly need to look good and be built quickly.

How to approach HTML pages in your organisation

Since the feature is already on, it pays to decide before the first hundred pages appear:

1. Decide where HTML pages make sense. On the main intranet sites it is reasonable to switch them off (and to check that this really applies to Copilot too); on project and team sites you can leave them on.
2. Prepare an approved starter template. One HTML file with corporate colours, fonts and basic elements that both authors and Copilot start from. Tests showed that Copilot adopts a concrete style stored in Site Assets exactly — a vague “match the theme” instruction doesn’t work.
3. Watch domains and data. The list of allowed external domains (Site settings → HTML Field Security) needs to be managed deliberately. With live data, remember that the whole list goes to the browser, including columns that aren’t displayed.
4. Give every page an owner. Someone who will maintain it when the data, the colours or the author change.
5. Plan for a rebrand. When the corporate look changes, HTML pages belong on the list of things that have to be reviewed by hand.

How we do it

We build our EasyPortal 365 apps on the SharePoint Framework, and we don’t see HTML pages as a replacement for them — we see them as a complement. The reason is standardisation. All our apps share one design system and one component library: tables, forms, panels and headers look and behave the same in CRM, in document management and in fleet management. We make a fix or an improvement in the shared library once, and with the next release of the apps it reaches every customer. The apps inherit the organisation’s colours from a central setting, are designed for mobile as well (most of them also run in Teams), respect SharePoint permissions and write data to lists that can be backed up, searched and audited.

An HTML page does none of this, and isn’t meant to. But for a quick, good-looking, one-off presentation it is excellent. That’s why we don’t recommend banning it — just giving it a clear place.

Key takeaways

1. HTML pages are fast, flexible and secure. Ideal for presentations, tools and dashboards over read-only data.
2. They can’t write, remember nothing and don’t know who is looking. For anything where the user does something, you need an app.
3. Every HTML page is a stand-alone original. Without a template and rules, the intranet breaks up into pages that each look different and have to be fixed one by one after a theme change.
4. The feature is on and can’t be turned off at tenant level. It is worth deciding now where HTML pages may be created.

---

We help organisations set up intranet rules so that new Microsoft features bring value rather than chaos — as part of our governance design. And if you are looking for apps that work consistently and long-term in SharePoint and Teams, take a look at EasyPortal 365 apps or get in touch.

Sources: Microsoft Message Center MC1479517 (25 Sep 2026); Microsoft Support — Create, upload, edit, and publish HTML pages in SharePoint; Microsoft SharePoint Blog — Publish rich and interactive content with HTML pages in SharePoint (22 Oct 2026, including Microsoft’s replies in the discussion); Microsoft Learn — Overview of the SharePoint Framework; independent tests by Denis Molodtsov — SharePoint HTML pages: what they can and cannot do and part 2, experiments after GA.