Stop pasted URLs from turning into third-party embeds
Disable Embeds removes WordPress's oEmbed system entirely, front end and back, then lets you re-enable exactly the providers your content actually uses.
- Removes the embed script, discovery links and rewrite rules.
- Stops other sites from embedding yours through the oEmbed API.
- Scans your own published content to find which providers you actually use.
- Keep individual providers active with a per-provider allow-list.
What does Disable Embeds do?
When the disable_embeds module is active, TOWP_Disable_Embeds dequeues the wp-embed script, removes both registered instances of the oEmbed discovery link callback from the <head>, strips the the_content filters that convert a pasted URL into an embed, disables oEmbed auto-discovery for external providers, and removes the /embed/ rewrite rules. It also forces oembed_response_data to return false, so other sites can no longer embed yours through the oEmbed API. Already-saved core/embed blocks stop rendering unless their specific provider has been explicitly allow-listed, in which case the module resolves the embed directly with wp_oembed_get() and swaps it back in.
A pasted link becomes a third-party request on your page
Every embed pulls in a script and a connection to another server, and by default WordPress lets that exchange run both ways.
Every embed loads someone else's resources
A YouTube or Twitter embed isn't just a video player or a card; it's a script and a network request to that provider's server, running on every page it appears on.
It's reciprocal, and rarely reviewed
WordPress's oEmbed system also lets other sites embed yours by default, an exchange most site owners never actually decided to make.
Off by default, on where you choose
The module removes the entire oEmbed system, then gives back exactly the providers a site's own content actually needs.
The whole system removed, not just hidden
The embed script, discovery links, rewrite rules and content filters are all removed, not just visually suppressed.
Your site stops embedding out, and being embedded
Both directions of the oEmbed exchange are closed: pasted URLs stop becoming embeds, and other sites can no longer pull content from yours through the API.
A scan built from your real content
Instead of guessing which providers to re-enable, the module scans your own published posts for embed blocks already in use.
A full removal, with a precise way back
Every capability below is present in the supplied PHP class and its settings registration.
wp-embed.min.js dequeued
The embed script that powers auto-resizing iframes is removed from the front end entirely.
Both callback instances removed
WordPress registers its oEmbed discovery link callback twice, at priority 4 and 10; the module removes both, since leaving either active keeps the link in the page head.
Other sites can no longer embed yours
Forcing oembed_response_data to return false makes the site's own oEmbed API respond with nothing, closing off the other direction of the exchange.
Saved embeds suppressed, not broken
An already-published core/embed block stops rendering cleanly rather than showing a raw, unconverted URL.
Re-enable exactly what's needed
Any specific provider can be kept active while every other embed stays disabled, resolved directly through wp_oembed_get() when allowed.
Finds providers your site actually uses
A scan searches up to 500 published posts for embed blocks already in the content, so the provider list reflects real usage, not a generic list.
Where controlling embeds helps most
The module supports any site rethinking how many third-party scripts its pages actually need.
Reducing third-party requests
Cut the number of external scripts and network requests a page makes, without losing the embeds a site actually relies on.
Privacy-conscious sites
Stop handing visitor data to third-party embed providers by default, keeping only the ones a genuine editorial decision has kept.
Preventing your content from being re-embedded
Close off the oEmbed API so other sites can't pull cards or previews from your own pages without asking.
Fewer scripts, precisely by design
The module combines a real removal with a granular way to keep exactly what's needed.
One less script, a bounded, cached scan
The verified implementation removes ongoing weight from every page and keeps its own scan lightweight.
One fewer script on every page
Dequeuing wp-embed.min.js removes a script from every front-end page load, regardless of whether that page has an embed.
A cached, bounded scan
The provider scan checks up to 500 posts and caches its result for 12 hours, rather than scanning the database on every page load.
Cache invalidated only when content changes
The provider cache clears whenever a post is saved, so the list stays accurate without needing a constant background scan.
Closed in both directions, reopened deliberately
The code removes every path a URL can turn into an embed, and validates anything it's asked to bring back.
Both discovery callbacks removed
Since WordPress registers the discovery link twice, removing only one would still leave a working link in the page head; the module removes both.
The site's own oEmbed API is disabled
oembed_response_data returning false means the reciprocal risk of other sites embedding this one is closed off entirely.
Provider allow-listing is explicit
A provider only stays active if its specific option is enabled; nothing re-activates by default.
URLs are validated before resolving an allowed embed
A URL for an allow-listed provider passes through esc_url_raw() before being sent to wp_oembed_get().
Built around native WordPress oEmbed and block APIs
The supplied code integrates through APIs present in WordPress core. No compatibility claim beyond the verified implementation is assumed.
wp_head, priority 4 and 10
Removes wp_oembed_add_discovery_links at both registered priorities, along with wp_oembed_add_host_js.
the_content
Removes WP_Embed's autoembed and run_shortcode filters, the mechanism that normally turns a pasted URL into an embed.
render_block_core/embed
Intercepts the core/embed block's output directly, since a saved embed block only stores the URL and depends on the content filters this module removes.
TheOneWP versus common alternatives
Compare the verified Disable Embeds implementation with a typical single-hook embed-removal snippet.
| Capability | TheOneWP Disable Embeds | Other common solutions |
|---|---|---|
| Removing the embed system | Script, discovery links, filters and rewrite rules all removed | Often only removes the discovery link, leaving other paths active |
| Blocking incoming embeds | The site's own oEmbed API is disabled too | Rarely addressed by a typical embed-removal snippet |
| Choosing which providers to keep | A per-provider allow-list, built from real usage | Usually all-or-nothing |
| Finding what to allow | Scans actual published content for embed blocks | Requires manually reviewing every post |
| Administration | One toggle plus a scan button in TheOneWP settings | Requires a separate plugin or manual code |
Take control of embeds in four steps
Scan before assuming nothing on the site needs a provider re-enabled.
Enable Disable Embeds
Activate the module from the TheOneWP settings; the whole oEmbed system stops working immediately.
Scan for providers already in use
Use the "Scan site for embed providers" button to find which providers your published content already relies on.
Allow-list what you need
Keep the specific providers your site actually uses active, leaving everything else disabled.
Rescan after adding new embed types
Run the scan again if content using a new provider gets published later.
Re-enable narrowly and deliberately
The scan does the finding; a bit of discipline keeps the allow-list from growing wider than it needs to.
Scan before assuming nothing needs to stay active
A site with existing embedded content likely needs at least one provider re-enabled; the scan finds it quickly.
Allow-list narrowly
Keep only the providers actually found in content, rather than re-enabling more than the scan turned up.
Rescan periodically on active sites
A site publishing regularly can pick up new providers over time; a periodic rescan keeps the allow-list accurate.
Check embedded content after enabling
Confirm posts that used to show an embed either still work, if allow-listed, or degrade cleanly, if not.
Avoid assumptions that break existing content
The module has a defined scope and a scan-then-allow rhythm worth understanding before enabling it.
Enabling the module without scanning first
A site with existing embeds can lose them entirely if no provider gets allow-listed after enabling the module.
Forgetting the scan only covers published content
Draft or unpublished posts with embed blocks won't be found until they're published and the scan runs again.
Expecting the provider list to update instantly
The scan result is cached for 12 hours and refreshes when a post is saved, not on every single page load.
Disable Embeds FAQ
These answers come directly from the verified class and its settings registration.
What does Disable Embeds do?
It removes WordPress's oEmbed system entirely, stopping pasted URLs from becoming embeds and stopping other sites from embedding yours, with an option to keep specific providers active.
Will this break embeds already in my content?
By default, yes, unless the specific provider they use is allow-listed; the built-in scan helps find which providers to re-enable.
How does the scan know which providers to suggest?
It searches up to 500 published posts for core/embed blocks already saved, and lists the providers it finds.
Can I keep just one provider, like YouTube, active?
Yes. Each discovered provider gets its own toggle, so only the ones you choose stay active while everything else stays disabled.
Does this stop other websites from embedding my content?
Yes. The module disables the site's own oEmbed API response, so other sites can no longer pull an embed from yours.
How often does the provider list refresh?
The scan result is cached for 12 hours and automatically clears whenever a post is saved, so it stays current without scanning constantly.
Does this remove the wp-embed script from every page?
Yes. wp-embed.min.js is dequeued from the front end regardless of whether the current page actually has an embed.
Is there a separate button to rescan for providers?
Yes. A "Scan site for embed providers" button re-runs the content search on demand.
What happens to an embed from a provider that isn't allow-listed?
The saved block stops rendering cleanly rather than showing a raw, unconverted URL.
Who can change which providers are allowed?
Only an administrator with access to the TheOneWP settings screen.
Stop every pasted link from loading a third party's script.Keep only the embeds you actually chose.
Use Disable Embeds to remove WordPress's oEmbed system and re-enable exactly the providers your content needs.