Every time Microsoft announces something with the word "HTML" and the word "SharePoint" in the same sentence, someone on the internal communications team smiles. Finally, they think, we will be able to upload the page the agency designed, with our fonts and our colors, without wrestling with web parts. And someone on the tech team gets nervous, because they have seen this movie before.
This week the movie came back. Microsoft posted in the Message Center that SharePoint Online will accept HTML pages as one more page type, alongside the usual ASPX pages. You can create them with Copilot, upload them from another tool, edit them and publish them.
It sounds like a revolution. It is something else, more modest and more useful than it looks. Let's take it step by step.
What is coming and when
The announcement is MC1479517, tied to roadmap item 569208. Public preview starts in early October 2026, and worldwide general availability rolls out between mid-November and late December.
In practice, page authors get three new paths: create an HTML page from a site's + New menu, ask Copilot for one from the floating button, or upload an .html file (or a whole folder with its assets) straight into the Site Pages library. The pages live there, with the same permissions and governance the site already has.
What you need to use it
The list of requirements is short, and it has a couple of surprises:
- A switch per site. Before anyone can upload HTML, a site owner has to go to Site Pages, open File types and turn on Allow HTML files. Without that, the option does not show up.
- Copilot only to create with Copilot. A Microsoft 365 Copilot license is required for the assisted creation screen and the editing chat. Uploading your own HTML, editing text, publishing, sharing and viewing the page need no license.
- Ten megabytes per file. That is the maximum size for an HTML file in Site Pages.
- An allow list for external links. For a link to another domain or another tenant to work, the site admin has to add the domain under HTML Field Security.
- No global switch. According to Microsoft's documentation, the feature cannot be disabled or restricted at the tenant level. The only brake is each site's toggle.
That last point deserves a pause. If your organization has hundreds of sites, the decision about who can publish HTML is spread across hundreds of owners. For a governance team, that is a conversation worth having before November, not after.
A sealed room
Here is the part that changes every expectation. SharePoint does not serve that HTML the way a web server would. It locks it inside a sandboxed iframe with a very strict Content Security Policy (CSP), isolated from the header, the navigation and the rest of the site.
Inside that room, JavaScript runs, but it cannot get out. No fetch, no external API calls, no localStorage. Denis Molodtsov, a Microsoft 365 architect, took the viewer apart with browser developer tools during Targeted release and documented what no official page says: code inside the iframe does not know who the user is, has no page context, and cannot call either the SharePoint REST API or Microsoft Graph.
It cannot embed other iframes either, so a Power BI tile, a Forms survey or a Stream video stay out. And every link, regardless of its target attribute, opens in a new tab.
Microsoft did not build a place to run code. It built a viewer for a new format, just like the one that already existed for PDF.
There is one detail to validate when it reaches your tenant. The official documentation, updated on September 30, says the sandbox supports five libraries served from a Microsoft CDN: Chart.js, Mermaid, React, Fluent UI and Babylon. In the August tests, before the preview, no external library would load. That is probably exactly what changed, but it is worth confirming with a test file.
"Live" data that is really a snapshot
The most interesting feature is connected data. Copilot can generate an HTML page that shows the contents of a SharePoint list, an Excel workbook or a CSV, and that refreshes every time it is opened.
The trick is that the HTML never fetches the data. It declares in a configuration block which sources it needs, and the SharePoint page, outside the iframe, pulls the rows and hands them over before the file renders. Up to 100,000 rows per source, every column included, with no paging and no follow-up queries.
Filtering, sorting and searching work, because they happen in memory. Writing back does not. Refreshing means reloading everything from scratch. It is a snapshot taken again each time someone opens the page, not a connection.
HTML pages versus SPFx
For anyone building portals, the inevitable question is whether this replaces the SharePoint Framework. The comparison answers it:
| HTML page | SPFx web part | |
|---|---|---|
| Deployment | Upload a file | Package in the App Catalog |
| Who builds it | Any author, or Copilot | A developer |
| User context | None | Full (identity, site, language) |
| REST and Graph | Blocked | Available with approved permissions |
| Data | Lists, Excel, CSV, read only | Any API, read and write |
| External calls | Blocked | Allowed through trusted origins |
| Navigation | Always a new tab | Normal |
| Site theme | Not inherited by uploaded HTML | Inherited |
| Page composition | A whole, isolated page | A piece combined with other web parts |
| License to build | Copilot if you use Copilot | None extra |
What matters most in a real project sits in the middle rows. A KPI that respects user security, a form that saves to a list, a query to the Power BI Execute Queries API (as we covered here), a menu that navigates: all of that is still SPFx territory.
Five warnings before you get excited
- It is not for building an intranet. If every click opens a new tab, a portal made of HTML pages turns into a maze. For home pages, menus and department pages, modern pages are still the way.
- The HTML the agency made probably will not work as is. External stylesheets, web fonts, third-party scripts and images by URL run into the sandbox. You will need to embed assets or rebuild parts.
- The data is not indexed. Search sees the file, but not the rows injected when it opens. Nobody will find that page by searching for something that appears in its table.
- Copying is not migrating. List references live inside the HTML itself. A file copied to another site keeps reading the original list, and migration tools do not know how to fix that.
- Governance sits with each site. With no tenant-level control, it is worth defining now a policy on which sites enable HTML and who reviews what gets published.
Where it shines
All that said, the feature has a clear and valuable place. It is the perfect format for Copilot to hand over finished work: a project status report, a visual brand guide, a read-only dashboard over a list, an executive summary with filters. Something you ask for in natural language, review, adjust with another request and share.
And it has an economic upside few people mention: people who view the page do not need a Copilot license. A handful of authoring licenses can serve a whole organization of readers.
The point
HTML pages are not a back door to developing on SharePoint without SPFx. They are a new file type, designed to give AI a format it can write in one pass. For read-only reports, that is great news. For portals, applications and integrations, the architecture does not change.
The key is not to mix the two up when planning. Use HTML where showing is enough, and SPFx where you need to know who is looking, connect systems or save something.
Is your organization figuring out how HTML pages fit into its SharePoint intranet or portal? Let's talk at macareno.net.
Sources
- Create, upload, edit, and publish HTML pages in SharePoint, Microsoft Support
- SharePoint: HTML pages (MC1479517), M365 Admin
- MC1479517 SharePoint HTML pages, PUPUWEB
- SharePoint gets HTML pages support, Erik365
- SharePoint HTML pages, what they can and cannot do, Denis Molodtsov
- What's New in Copilot in SharePoint: August 2026, Microsoft Tech Community