For years, the answer to “Can we add our own HTML to a modern SharePoint page?” was complicated. You could use standard web parts, embed content from another site, or build a custom SPFx web part. But the classic Script Editor approach did not carry over to modern pages.

Now there is another option: HTML pages in SharePoint Online. Microsoft documents a workflow for creating an HTML page with Copilot or uploading an existing HTML file into the Site Pages library, then editing, publishing, and sharing it alongside regular SharePoint pages.

That sounds like a small change. For teams building intranets, campaign pages, visual guides, or lightweight internal experiences, it is worth a closer look.

What actually changed?

A site owner can open the Site Pages library, select File types, and turn on Allow HTML files. Authors with the appropriate permissions can then upload an .html file, upload a folder containing the page and its supporting files, or create a page through the Copilot experience. The maximum HTML upload size is 10 MB.

The licensing distinction matters: uploading an existing HTML page, editing its text directly, and publishing it do not require a Microsoft 365 Copilot license. Creating or changing the page through the Copilot chat pane does require one.

This is a different page type and workflow from pasting arbitrary HTML into the Text web part of an existing modern .aspx page. The Text web part still does not offer HTML source editing, and modern pages still do not include the classic Script Editor and Content Editor web parts.

HTML page option in the SharePoint New menu

Where I would use HTML pages

Imagine an internal project landing page with a custom timeline, a visual explanation of a process, or a branded guide that does not fit neatly into the standard page sections. If the experience is largely self-contained, an HTML page may be a practical way to deliver it inside SharePoint’s publishing flow.

You can also start with a page designed elsewhere and upload it. SharePoint stores uploaded non-HTML assets in Site Assets when they are embedded in the HTML or included in the uploaded folder. Once the page is in Site Pages, an author can edit text on the canvas and publish it for people who already have access. Publishing itself does not grant new permissions.

That last point is easy to miss: the page is still part of a governed SharePoint site. Ownership, review, access, and maintenance need to be decided just as they would for any other intranet content.

Where the boundaries are…

“HTML page” does not mean “anything a browser can run.” SharePoint renders these pages inside a sandboxed iframe, isolated from the surrounding SharePoint page. Microsoft’s documentation says arbitrary fetch requests and outbound API calls are blocked. It also lists restrictions around external scripts and libraries: JavaScript in the same HTML file is supported, while CDN-loaded scripts are not; supported libraries are provided through Microsoft-managed versions.

There are publishing differences too. At the time of writing, Microsoft’s feature table lists no promotion to a news post, scheduled publishing, co-authoring, reactions or comments, or saving the HTML page as a template. Uploaded HTML also does not automatically inherit the site’s branding.

Those are meaningful limits. A static or self-contained visual page is one thing. A business application that needs to call APIs, interact deeply with SharePoint data, manage permissions, or serve as a reusable component across many pages is another.

HTML pages, Embed, or SPFx?

The right option depends on what you need to build. For standard intranet content, documents, news, and navigation, I would start with a modern SharePoint page and its built-in web parts.

If the goal is a self-contained visual page or guide, the new HTML page workflow is worth exploring. If the content already lives on another website and that site allows it to be displayed elsewhere, the Embed web part may be enough.

For a custom component that needs to work with SharePoint or Microsoft 365 data, I would look at an SPFx web part or extension.

The Embed web part is sometimes confused with HTML pages. It displays content from another website using a URL or iframe-based embed code; it does not accept embed code containing <script> tags. SPFx remains Microsoft’s recommended development model for custom SharePoint experiences and integrations.

My perspective

HTML pages give authors and developers another way to create a tailored experience. A custom layout no longer has to become a web part project by default. I would still start with a few practical questions: Who will maintain the page? Does it need live data? Must it follow the site’s branding? Should it be published as news or reused elsewhere?

For a page focused on content and visual presentation, I would test the new HTML workflow. If the requirements start to look like an application, I would design and build it as one.

The question I would ask is: Which SharePoint approach best fits what this page needs to do?