SharePoint Online Modern Script Editor and Its Consequences

Modern SharePoint has no equivalent of the classic Script Editor web part — that’s a deliberate security decision, not a missing feature. Custom script is blocked by default on every modern site, and the workarounds people reach for come with real governance consequences that go beyond “test your code first.” This post covers what’s actually blocked, how to override it if there’s a genuine need, and the 2026 governance changes that make this a worse idea now than it was a couple of years ago.

In this post: Why there’s no Script Editor anymore · Enabling custom script, if you really need to · The community Script Editor web part · The 2026 governance changes · The real consequences · When would you actually use this? · Related reading

Why there’s no Script Editor anymore

Custom script — arbitrary JavaScript or HTML dropped onto a page via the classic Script Editor or Content Editor web parts — is disabled tenant-wide on modern sites by default. The underlying setting is a site property, commonly still referred to by its old name NoScriptSite, controlled through DenyAddAndCustomizePages. Microsoft’s replacement is the SharePoint Framework (SPFx): client-side web parts and extensions built with TypeScript and modern web tooling, reviewed and deployed through an app catalog rather than pasted directly into a page. The difference isn’t cosmetic — SPFx solutions go through a real deployment and update pipeline; a Script Editor drop-in bypasses that entirely, which is exactly why it’s blocked by default now.

Enabling custom script, if you really need to

It’s still possible to re-enable custom script on a specific site, and there are legitimate cases for it — migrating a legacy page that genuinely can’t be rebuilt yet is the most common. The command is a SharePoint Online Management Shell one-liner:

# 0 = custom script allowed, 1 = blocked (the default)
Set-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/yoursite" -DenyAddAndCustomizePages 0

Worth knowing before relying on this: on many modern sites the setting can silently reset back to blocked after around 24 hours unless the tenant’s broader settings actually permit the change to stick. A one-time PowerShell run that “worked” during testing isn’t a guarantee it stays enabled — verify it’s still set the way you expect before depending on it in production, not just immediately after running the command. Checking the current state is its own one-liner: Get-SPOSite -Identity "https://yourtenant.sharepoint.com/sites/yoursite" | Select-Object DenyAddAndCustomizePages — worth running as a scheduled check on any site depending on this, rather than assuming a setting made once stays put indefinitely.

The community Script Editor web part

PnP maintains an open-source SPFx web part that recreates the classic Script Editor’s behavior — dropping arbitrary script or HTML onto a modern page — packaged as a proper, deployable solution rather than a raw code-injection workaround. It lives at pnp/sp-dev-fx-webparts (worth noting if you’ve seen this linked elsewhere under the old SharePoint/sp-dev-fx-webparts organization and master branch — the project moved to the pnp org and main branch, and the old URL redirects but is worth updating in any bookmarks or internal docs). A recent update to the sample added support for loading scripts via the Function constructor specifically to stay compliant with Content-Security-Policy restrictions — a reminder that even the “safe” packaged version of this needs active maintenance to keep working as the security landscape around it tightens.

A one-time PowerShell run that enables custom script isn’t a guarantee it stays enabled — the setting can silently reset within about 24 hours depending on tenant configuration.

The 2026 governance changes

Two changes landed this year that make custom script a worse bet going forward, not a stable legacy option to lean on indefinitely: the tenant-level opt-out that some organizations used to permit custom scripting changes on classic publishing sites was retired starting March 15, 2026 — if a site was relying on that opt-out, it’s no longer available. Separately, custom scripting was disabled tenant-wide on the App Catalog site itself starting mid-January 2026, specifically to close off a security gap in the very site that’s supposed to be the trusted deployment point for SPFx solutions. Both changes point the same direction: Microsoft is tightening this further, not loosening it, so a script-injection workaround that’s tolerated today is a reasonable candidate to stop working entirely at some future date, without much warning.

The real consequences

Security exposure that’s hard to audit. Injected script bypasses the review process SPFx solutions go through in an app catalog — there’s no equivalent gate catching a compromised or poorly written script before it reaches production.
It breaks without warning. Between the 24-hour reset behavior and Microsoft’s ongoing tightening of custom script governance, code that depends on this staying enabled is depending on something actively being deprecated, not a stable platform feature.
No real update path. A script pasted directly onto a page doesn’t get versioned, tested, or rolled back the way an SPFx solution deployed through an app catalog does — when it breaks, there’s no packaged prior version to fall back to.

When would you actually use this?

Migrating a legacy classic page that genuinely can’t be rebuilt as SPFx yet, as a temporary bridge — with an actual plan to replace it, not indefinitely.
A short-lived proof of concept where the overhead of a full SPFx solution isn’t justified for something that will be thrown away in a week.
You’re not sure — in almost every other case, a proper SPFx web part or extension is the better long-term choice: it survives the governance tightening described above, gets reviewed before deployment, and has a real update path.

Start Your SharePoint with SPFx — getting started with the actual replacement for Script Editor.
Are SPFx Solutions Still Ideal and Safe? — the security and longevity case for SPFx over script injection, in depth.

Custom script isn’t gone by accident, and re-enabling it is a workaround with a shrinking shelf life, not a supported long-term customization path. If a page genuinely needs this level of control, that’s usually the signal to build it as SPFx properly rather than reach for the workaround that skips the review process.