SharePoint now lets users with the right permissions create HTML pages, including from a Copilot prompt, rolling out between October and December 2026. The pages are useful and the permissions model is unchanged, so this is not a security scramble. The real question this new feature raises is different: when creating a rich page takes one afternoon, which of those pages should your business actually depend on, and who owns them once they exist? That is a governance decision, and it is yours to make.
The SharePoint community is buzzing about the new HTML pages that Copilot can now generate in one prompt. It got everyone excited, but it also raised some important questions.
Every time something new lands in SharePoint, the first question is: what is that going to replace? And I'm already hearing the following one, which is: if I can describe a page and have it built in minutes, do I still need to invest time in a proper build? Some wonder if this is the same as Custom Script, while others are asking about permissions.
These are all valid, practical questions, but I'm seeing one more important one that is missing in those conversations: which of these HTML pages become relevant to your business, and who will take ownership of them?
There's lots to unpack here, so let's dive in.
What SharePoint HTML Pages Actually Are
SharePoint is adding a second page format alongside its existing ASPX pages. You can create an HTML page from the + New menu, upload an existing .html file, or describe the page you want to Copilot and have it draft one for you, then edit the text directly or refine it through the chat pane. Microsoft confirmed the rollout in message MC1479517: public preview in early October 2026, general availability from mid-November through late December.
The pages live in the Site Pages library next to your ASPX pages, and they run on your existing permissions. Publishing one grants no new access. Microsoft's own line is that no admin action is required before rollout, and for the mechanics of turning it on, that's true.
What makes this more than a new editor is Copilot. The most common way these pages get built may end up having very little to do with writing HTML. You describe a project status page with a roadmap and an FAQ, point Copilot at a few documents for context, and it produces the page. The HTML underneath becomes almost invisible to the person creating it.
That is a big shift in content ownership, which should be handled with care. The easier creation gets, the more of it we can expect. The good news is that Microsoft thought about where this could lead and made sure these pages don't run wild. Based on current technical analysis, these HTML pages appear to run within a sandboxed model, which clearly says this is not the free-for-all some people are expecting.
Who Turns HTML Pages On
Control over whether HTML pages can be created or uploaded sits at the site level. Microsoft's guidance is that, where available, organizations should check the site-level settings that determine this for the Site Pages library.
The point to hold onto is where that control lives: with the site, not centrally. The decision to allow these pages is made site by site, and there is no single tenant-wide switch to turn them off everywhere. That is the whole reason this becomes a governance question rather than a one-time IT task, and I'll come back to it.
Is This the Return of Custom Script?
Anyone who worked with SharePoint for long will feel a flicker of recognition here. HTML, JavaScript, custom pages. We did this before, with Script Editor web parts and custom script, and it produced two decades of creative and occasionally terrifying solutions that nobody could govern after the fact.
HTML in SharePoint is not going back to that, and Microsoft's own guidance on custom script is blunt about why the old model was a problem: once you allow arbitrary script, you can't scope what it does, you can't audit what was inserted, and you can't reliably remove it. Microsoft has spent years steering custom work toward the SharePoint Framework (SPFx) instead.
HTML pages are the opposite of that old model by design. They render inside a sandboxed iframe, isolated from the surrounding page. A Content Security Policy applies. Outbound calls are restricted, you can't pull arbitrary scripts from any external source, and the libraries you can use come from a Microsoft-managed set. Even browser storage is off. Microsoft gave authors more creative freedom at the front and put firm limits on what the code can reach, on purpose. More freedom to create, hard limits on what that creation can touch: that pairing is the thing to understand about this release.
Do HTML Pages Change Who Can See My Content?
No, an HTML page doesn't change who sees what. It lives in Site Pages and inherits the same permissions as any other page there, so publishing it doesn't expand access. Only people who could already see the page can see it once it's live.
An AI helped write the content, but it didn't touch the authorization model, and that’s important for compliance and information management.
Which HTML Pages Should Your Business Depend On?
Now that we've moved the technicalities out of the way, let's talk about the more important question: judgment.
Businesses don't care whether something was written in HTML, React, or anything else. They care whether their people can use it, whether it can be supported, whether it still works in five years, and what happens when the person who made it leaves. Those are the questions that decide whether a page is a nice experiment or a thing the company now runs on.
A sandboxed HTML page responds to some of those requirements well, and for others it's not enough. So instead of asking "can we build this," I ask what the thing is becoming. In practice it falls into one of three tiers:
- The experiment. Someone has an idea and wants to see it work. HTML is perfect here: low friction, fast, Copilot does most of the lifting, minimal investment. Optimize for speed and let it expire when it's served its purpose. Most pages should live and die here, and that's completely fine.
- The page people started to rely on. The page stopped being a test and became part of how a team works, usually without anyone deciding it should. The moment that happens, it needs an owner, a review, and a place in your content lifecycle. This is the dangerous tier, not because the page is risky, but because the transition doesn't come with a bang. It sneaks in gradually and can stay invisible for too long.
- The business-critical capability. People depend on this page every day, it needs real data integration, security, and support, and it has to keep working through staff changes and platform updates. This is where a sandboxed page runs out of room. When a page needs API integration, external services, or application logic the sandbox won't allow, it has outgrown HTML and needs to become a properly built, integrated, supported application. That's the ceiling, and SPFx is what stands above it.
So HTML didn't replace that, it expanded the toolbox underneath it. The skill now is to match the tool to what the page is becoming, not to how easy it was to make.
What a Site Owner Should Decide Now
Remember that "no admin action required" line. For the rollout, it's accurate. For governance, I'd put a large asterisk next to it.
There's a site-level control, Allow HTML files, and there is currently no tenant-wide switch to turn this off everywhere. That one fact changes the picture: it makes the Site Owner a governance actor, whether they signed up for the role or not.
The decisions land with them, and most of those decisions are better made before the pages start multiplying than after:
- Who may generate pages with Copilot, and on which sites. The licensing decides who technically can; you decide who should.
- Which external domains are trusted. When a page references outside resources, someone has to approve the domain through HTML Field Security. That's a small setting, but it becomes a real governance question once hundreds of pages exist.
- How generated pages get reviewed before anyone relies on them. A page Copilot produced from a prompt is a draft, not a vetted source, until someone treats it as one.
- Who owns each page over time. This is the one that gets skipped. A Copilot-generated page is organizational content, not disposable AI output. It needs an owner, it needs maintaining, and eventually someone has to know when it should be archived or deleted.
All of this is ordinary content governance, applied to a kind of content that's about to be created far faster than before. The organizations that handle this well won't be the ones that lock HTML pages down or the ones that wave them all through. They'll be the ones who decided, up front, who can publish what, who owns it, and when it retires, so governance sits at the point of creation instead of chasing the sprawl later.
That's the same principle BindTuning builds governed provisioning around: ownership, structure, and lifecycle applied when something is created, not bolted on after it's already everywhere.
When creating a page takes a few hours or less, the advantage doesn't go to whoever builds the most or the fastest. It goes to whoever decided, in advance, what gets to become permanent and how it will be governed.
FAQ
How do I enable HTML pages in SharePoint?
HTML pages are controlled at the SharePoint site/page-authoring level. Before rollout, Site Owners and admins should review who can create and publish pages in Site Pages and check the available controls for HTML creation or upload as the feature appears in their tenant.
Is there a tenant-wide switch to turn HTML pages off?
Not currently. Microsoft has not provided a tenant-level control to disable HTML pages across the whole environment. The control that exists is the site-level Allow HTML files setting. That means governance has to be handled site by site, through Site Owners and your authoring guidance, rather than through one central off switch.
Does HTML replace SPFx?
No. HTML pages are a fast way to build rich content inside the sandbox. SPFx is for when a page outgrows that sandbox and needs real data integration, external services, application logic, or long-term supportability. HTML expands your options for lightweight pages; SPFx remains the model for genuine applications. The decision depends on what the page needs to become, not on which is newer.
Do HTML pages have all the features of a normal SharePoint page?
Not at launch. HTML pages are a distinct page type with their own capability model, and some familiar features aren't supported initially, including co-authoring, scheduling, reactions and comments, saving as a template, and promoting a page to News. Amplification to Teams and Viva Engage also works differently. Treat an HTML page as its own format with its own limits, not as a modern page written in HTML.
