SharePoint HTML Pages: What They Mean for Your Intranet

Key Takeaways

• HTML pages extend the SharePoint page model; they don’t replace standard modern pages, templates or web parts.
• The biggest opportunity is selective: richer visualisation, interaction or layout where standard SharePoint can’t meet a clear requirement.
• Most organisations are likely to need a mixed publishing model, with standard pages remaining the default and HTML used for specific experiences.
• Greater design freedom increases the importance of accessibility, consistency, ownership and long-term maintenance.
• Silicon Reef recommends: Start with a small number of use cases before deciding who should create HTML pages or how widely the capability should be enabled.

Microsoft has introduced HTML pages in SharePoint, giving organisations another way to create richer, more interactive experiences alongside standard modern pages.

Microsoft already provides detailed guidance on how to create, upload, edit and publish HTML pages, including current licensing, supported features and technical limitations. If you’re looking for the product instructions, start with Microsoft’s official SharePoint HTML pages guidance.

This guide takes a different angle. It explores what HTML pages could mean for your intranet, your SharePoint design approach, your content authors and your governance model, drawing on Silicon Reef’s experience of designing and delivering SharePoint intranets.

Jump to:

• What are HTML pages in SharePoint?
• SharePoint HTML pages vs standard SharePoint pages
• What do HTML pages mean for SharePoint design?
• What do HTML pages mean for my intranet?
• When should I use HTML instead of a standard SharePoint page?
• Could HTML reduce the need for custom SharePoint development?
• Could HTML make my intranet harder to manage?
• Who should be allowed to create HTML pages?
• How will HTML pages affect content authors?
• How do SharePoint HTML pages work?
• What should we do before enabling SharePoint HTML pages?

What are HTML Pages in SharePoint?

HTML pages are an additional page format within SharePoint. They don’t replace the standard page builder experience, which still uses sections and web parts. HTML pages use HTML to control page content, layouts and behaviours, while still sitting within the surrounding SharePoint site experience, including its header, navigation and footer.

They are stored in the Site Pages library alongside standard SharePoint pages. Authors can create HTML pages with Microsoft Copilot or upload existing HTML, provided the feature is enabled and they have the appropriate permissions.

What this means in practice: HTML gives SharePoint teams another route when a requirement doesn’t fit comfortably within the standard page canvas. It should be treated as an additional option, not a new default for everyday publishing.

SharePoint HTML Pages vs Standard SharePoint Pages

The main difference is the balance between structure and freedom. Standard SharePoint pages give authors a controlled canvas, reusable web parts and familiar publishing patterns. HTML pages provide more control over layout, styling and interaction, but place more responsibility on the people creating, reviewing and maintaining the experience.

SharePoint HTML pages and standard modern SharePoint pages can sit alongside each other, but they suit different requirements.

HTML pages aren’t a replacement for the way organisations already create content in SharePoint. For most intranets, standard pages will continue to make sense for news, policies, departmental content and other information that needs to be easy to create, repeat and maintain.

HTML becomes more useful when there’s a clear reason to step outside those standard patterns, whether that’s a particular interaction, a more visual way of presenting information or a one-off experience that would otherwise require custom development.

Silicon Reef recommends: Don’t think of this as choosing between HTML and standard SharePoint pages for your whole intranet. Standard pages should remain the default for most organisations because they’re easier to repeat, govern and maintain. HTML pages are most useful as an additional option when a particular experience needs more flexibility than the standard page model can provide.

What do HTML Pages Mean for SharePoint Design?

HTML pages widen the design possibilities in SharePoint, but more freedom doesn’t automatically produce a better employee experience.

One of the strengths of modern SharePoint is that its constraints create consistency. Sections, web parts, templates and site designs give people familiar patterns as they move around an intranet. They also make it easier for content authors to create and maintain pages without relying on specialist design or development skills.

HTML pages loosen some of those constraints. That can be valuable when a page genuinely needs a different visual or interactive treatment, but it makes the design system more important, not less. Organisations should decide which principles remain non-negotiable across both standard and HTML pages.

That includes:

• Brand elements like colour, typography, imagery and spacing
• Consistent navigation and interaction patterns
• Responsive behaviour across desktop, tablet and mobile
• Accessibility standards, including keyboard access, colour contrast and semantic structure
• Clear hierarchy and calls to action
• Rules for when a bespoke experience genuinely improves the outcome

Silicon Reef recommends: Treat HTML as an extension of your SharePoint design system, rather than an opportunity to step outside it. Individual pages can be more flexible while the overall intranet still feels coherent.

What do HTML Pages Mean for my Intranet?

For most organisations, HTML pages shouldn’t fundamentally change how the majority of intranet content is published. Standard SharePoint pages will still make sense for news, policies, departmental content, guidance and other information that benefits from consistent templates and straightforward authoring.

The change is around the edges of that standard publishing model. Organisations now have another option for experiences that might previously have required compromise, custom development or a separate tool outside SharePoint.

Examples could include a major transformation hub, an interactive employee guide, a visual project dashboard or a one-off campaign experience with requirements that don’t fit neatly into existing web parts.

The likely outcome is a mixed publishing model: standard SharePoint pages remain the default, with HTML used selectively where it solves a specific design, content or interaction problem.

When Should I use HTML Instead of a Standard SharePoint Page?

Start with the requirement, not the technology. Just because HTML pages offer greater flexibility, doesn’t mean they’ll always be the best option.

Use a standard SharePoint page when:

• The content follows a repeatable format
• Many content authors need to update it
• You need templates, news publishing, scheduling or co-authoring
• The page is part of a larger set that should behave consistently
• Standard web parts already meet the requirement

Consider an HTML page when:

• There’s a clear need for a more bespoke layout or interaction
• Information needs to be visualised in a way standard web parts can’t easily support
• You’re creating a specific experience rather than a repeatable content type
• A one-off requirement doesn’t justify developing and maintaining a reusable component
• The additional flexibility produces a clear benefit for the person using the page

Silicon Reef recommends: If a standard page and existing template can do the job well, use them. The additional flexibility of HTML should solve a real problem and justify the extra review and maintenance it may create.

Could HTML Reduce the Need for Custom SharePoint Development?

In some scenarios, yes. HTML pages may provide a simpler route when the requirement is for a single bespoke page, visualisation or interactive experience rather than reusable functionality.

Custom SharePoint components will still make more sense when functionality needs to be reusable, deployed consistently across multiple sites, managed centrally or integrated more deeply with Microsoft 365 and other systems.

HTML adds another step to the solution-design process. Before commissioning a custom component, it’s worth checking whether a standard page, an HTML page or a reusable SharePoint Framework solution is the most proportionate response.

Could HTML Pages Make my Intranet Harder to Manage?

They could, if they’re introduced without clear boundaries. If left unmanaged, HTML pages could lead to an uncontrolled sprawl of bespoke pages that look different, behave differently and depend on individual creators to maintain them.

Common management risks include:

• Too many one-off designs weakening the consistency of the intranet
• Pages that don’t meet accessibility or responsive-design requirements
• Unclear ownership after the original creator changes role or leaves
• AI-generated content or code being published without adequate review
• Business-critical experiences depending on skills held by one person
• Duplicate solutions being created for similar requirements

A lightweight approval and ownership model can reduce these risks without removing the flexibility that makes HTML useful.

Who Should be Allowed to Create HTML Pages?

There’s no single permission model that will suit every organisation. A global intranet with distributed publishing will need a different approach from a smaller organisation with a central content team.

In most cases, it’s sensible to begin with a limited group of experienced intranet, digital workplace, design or technical users rather than immediately making HTML another standard option for every content author.

A controlled start gives the organisation time to understand where HTML adds value, what skills authors need and what the review process should cover before access is widened.

How will HTML Pages Affect Content Authors?

Copilot lowers the barrier to creating more bespoke experiences, but bespoke content is less repeatable by nature. That creates a tension between creative freedom and efficient publishing.

Most content authors are likely to continue using standard SharePoint pages for routine work because templates and web parts make common publishing tasks quicker, safer and easier to hand over. HTML shouldn’t make everyday publishing more complicated than it needs to be.

Where content authors do use HTML, they may need additional guidance on prompting, accessibility, responsive design, testing and ownership. A polished-looking Copilot output still needs human review before publication.

How do SharePoint HTML Pages Work?

The points below summarise the practical product information most organisations will need. For detailed, current instructions, refer to Microsoft’s official documentation.

Creating and editing pages

Authors can create an HTML page with Copilot or upload existing HTML. Text can be edited directly on the canvas, while Copilot can be used for broader content and design changes. Uploaded pages can be stored, edited and published from the Site Pages library.

Microsoft Copilot licensing

A Microsoft 365 Copilot licence is required for Copilot-powered creation and editing. It is not required simply to upload existing HTML, directly edit page content, publish, share or view a page. SharePoint permissions still apply.

Supported content and data

Microsoft documents support for user-added images, overlay video, links to Office and PDF files, data from SharePoint lists and Excel, anchor links, JavaScript within the HTML file and selected Microsoft-managed libraries such as Chart.js and Mermaid. Microsoft also references CSV data in its announcement.

Security and permissions

HTML pages are rendered inside a sandboxed iframe. Microsoft applies Content Security Policy rules and blocks arbitrary fetch requests and outbound API calls. Publishing a page doesn’t give viewers access beyond their existing SharePoint permissions.

Current limitations

Current limitations include no news promotion, page templates, scheduling, co-authoring, reactions or comments. Third-party CDN scripts, arbitrary fetch requests, outbound API calls and some media and document-embedding scenarios are also unsupported. Microsoft currently specifies a 10 MB maximum HTML upload size, excluding assets copied into Site Assets.

For the latest product detail, see Microsoft’s support article and the Microsoft SharePoint announcement.

What Should we do Before Enabling HTML Pages?

Start with a small number of real business requirements rather than enabling HTML widely and waiting to see what people create.

1. Choose two or three use cases where standard SharePoint currently creates a genuine constraint.
2. Bring together the intranet owner, internal communications, SharePoint or digital workplace expertise, design and accessibility input.
3. Create and test the pages across devices and with representative users.
4. Review the effort required to maintain each experience after launch.
5. Use what you learn to define who can create HTML pages, what requires approval and where standard pages remain the default.

Before publishing an HTML page, check:

• Content accuracy and the quality of any AI-generated output
• Accessibility, including keyboard use and contrast
• Responsive behaviour across devices
• Alignment with the intranet design system
• Page performance
• Named ownership and a maintenance plan
• Whether a standard SharePoint page would meet the requirement more simply

Silicon Reef recommends: Test the operating model as well as the technology. A successful pilot should tell you not only what HTML can create, but who should create it, how pages are reviewed and how they will be maintained.