Custom Code in SharePoint: 4 Options and Their Limits

Someone asks for a countdown timer, a live dashboard, or a styled table that the standard web parts will not produce. There are four ways to answer that in SharePoint Online, and choosing between them is less about what each one can do than about where each one stops you.

One of the four is not really in the category at all, and it gets picked by mistake often enough to be the reason this post exists. Its name is SharePoint Embedded, and it does not put anything on a page.

In this post: Prerequisites · The four, at a glance · 1. The Embed web part · 2. HTML pages · 3. An SPFx web part · 4. SharePoint Embedded, which is none of the above · What about the Script Editor? · Picking one · Related reading

Prerequisites

Edit rights on a page for the first two options. Nothing more.
Site collection administrator to change the embedding allow list, which lives in Site settings under HTML Field Security.
Site owner to allow or block HTML files in the Site Pages library.
A build toolchain and app catalog access for SPFx. That is the real cost of option three, not the coding.

The four, at a glance

Option	Renders where	Where it stops you
Embed web part	iframe on the page	No script-tag embed codes, HTTPS only, allow list
HTML page	sandboxed iframe	Inline JavaScript only, no fetch, no localStorage
SPFx web part	the page itself	Nothing technical, but a toolchain and a deployment
SharePoint Embedded	nowhere	There is no page. It is an API

1. The Embed web part

The lowest effort option. Drop in the Embed web part, paste a URL or an embed code, and the content appears in an iframe. Good for a video, a Power BI report, a form, anything that already exists somewhere else and publishes an embed snippet.

Three constraints decide whether it will work, and the first catches people most:

Embed code must be iframe based. Embed codes that use script tags are not supported. Plenty of third-party widgets ship a script snippet and nothing else, and those simply cannot go here.
The URL must begin with HTTPS.
The domain must be allowed. A site collection admin controls this in Site settings under HTML Field Security, choosing between no embedding, a specific list of domains, or any domain. Microsoft advises against the last for security reasons. Blocked content shows “Embedding content from this website isn’t allowed.”

One more that is outside your control entirely: the target site can refuse to be framed. Allowing a domain on your side does nothing if the other end sends headers that forbid embedding, which many sign-in pages and SaaS dashboards do by default.

2. HTML pages

The newer option, and the one most people have not tried. You upload an HTML file to the Site Pages library, or generate one with Copilot, and SharePoint serves it as a page. Images and other assets land in the Site assets folder automatically.

SharePoint renders it in a sandboxed iframe that isolates the page from the surrounding header, footer and navigation, with Content Security Policy rules layered on top. That sandbox is the whole story, because it is strict:

JavaScript runs only when the code sits in the same HTML file. No CDN. No external libraries. No outbound API calls. No localStorage.

Inline JavaScript only. Script loaded from a CDN or an open source library location is not supported. The exceptions are Microsoft-managed builds of Chart.js, Mermaid, React, Fluent UI and Babylon.
No arbitrary fetch requests or outbound API calls. So a page that reads a list, calls Graph, or pulls a third-party feed is out.
No access to browser localStorage from inside the sandbox.
10 MB maximum per upload, excluding assets.
Links to outside domains still require that domain on the HTML Field Security allow list.

Also missing, and some of these matter more than the technical limits: no co-authoring, no comments or reactions, no private drafts, no promoting to a news post, no scheduling, no saving as a template. An HTML page is a published artifact, not a collaborative one.

Site owners control availability per site in the Site Pages library under File types, with an Allow HTML files toggle. They are on by default, and there is no tenant-wide off switch, which is a governance detail an admin reading this should probably go and check.

3. An SPFx web part

The only option with no ceiling. An SPFx web part runs as first-class code on the page, with the page context, the current user’s identity, and access to SharePoint and Graph APIs. Anything the other three cannot do, this can.

What it costs is not difficulty but process. A toolchain to install and keep current, a build step, a package, an app catalog, and a deployment with someone’s approval attached. For a countdown timer on one page that is a disproportionate amount of machinery. For anything that needs to read tenant data, handle permissions, or live for years, it is the only honest answer.

4. SharePoint Embedded, which is none of the above

This is the one that arrives by search result rather than by choice. The name reads as “embedded in SharePoint”. It means close to the opposite: SharePoint embedded in your application.

Microsoft’s own overview is blunt about it. SharePoint Embedded “isn’t the same as SharePoint Online sites or document libraries, the SharePoint Framework (SPFx), OneDrive APIs, or blob storage.” It is an API-only file and document platform with no standalone end-user interface and no no-code option, reached entirely through Microsoft Graph. Using it always means building an application.

Content lives in a dedicated storage partition inside the customer’s Microsoft 365 tenant, in what Microsoft calls a File Storage Container, which is effectively an API-only document library. The partition has no user experience of its own and is reachable only by the owning app. Billing does not touch Microsoft 365 storage entitlements either: it runs through an Azure subscription on a metered, pay-as-you-go model based on storage and API usage.

So if the task is “put something on a page”, this is not the tool. If the task is “my product needs document storage and I would rather not build versioning, co-authoring and compliance myself”, it is a serious option and nothing else on this list competes with it.

What about the Script Editor?

It still turns up as the first suggestion in a lot of older guidance. The classic Script Editor web part is gone from modern pages, and the community SPFx replacement depends on custom scripting being enabled on the site, which is a tenant-level decision with consequences well beyond one page.

HTML pages cover a slice of what people used the Script Editor for, with a sandbox around it. Not the whole slice, since the no-fetch and no-external-script rules rule out most of the interesting cases, but the simple ones.

Picking one

It already exists elsewhere and gives you an iframe snippet. Embed web part. Check the domain is allowed and the snippet is not script based.
Self-contained markup, maybe a chart, no live data. HTML page. Keep the JavaScript inline and stay under 10 MB.
It needs list data, the current user, Graph, or any API call. SPFx. The other two cannot reach any of that.
It needs to be commented on, co-authored, or published as news. A normal SharePoint page. HTML pages support none of those.
You are building a product that needs document storage. SharePoint Embedded, and ignore everything above.

SharePoint Online Modern Script Editor and Its Consequences explains the custom scripting setting behind the Script Editor section above, and why enabling it is a bigger decision than it looks.
Start your SharePoint with SPFx covers the toolchain that makes option three expensive, which is the part to understand before committing to it.
Are SPFx Solutions Still Ideal and Safe? is the longer answer on whether that investment still makes sense in 2026.

The honest summary is that three of these put pixels on a page and one does not, and the one that does not has the most confusing name of the four. Between the three that do, the question is never which is most capable, since SPFx wins that every time. It is how much machinery the request deserves.

A year ago I would have said SPFx for anything beyond an iframe, without much hesitation. HTML pages have changed that for a narrow band of cases, and I am still working out how narrow. Tell me in the comments if you have found the edge of it.