View the source of any WordPress site and scroll to the bottom. You’ll find a JavaScript file called wp-embed.min.js loading in the footer. It’s only 1.7 KB, so most people ignore it. But that script is the tip of an iceberg that includes discovery links in your , REST API endpoints, and rewrite rules — all for a feature most site owners never use.
Since WordPress 4.4, your site is both an oEmbed consumer and an oEmbed provider. That second part — provider — is what creates the overhead. And for the majority of business sites, portfolios, and WooCommerce stores, it’s completely unnecessary.
What is oEmbed?
oEmbed is a protocol that lets websites embed content from other sites by simply pasting a URL. Paste a YouTube link into the WordPress editor and it turns into a video player. Paste a tweet and it becomes an embedded card. That’s oEmbed consuming — and that part is genuinely useful.
The provider side is different. Since 4.4, your WordPress posts can be embedded on other WordPress sites. Someone pastes your post URL into their editor, and WordPress fetches a preview card with your title, excerpt, and featured image. To make this work, WordPress adds several things to every page:
wp-embed.min.js— JavaScript that handles the embed iframe communication- Two
discovery tags in— JSON and XML oEmbed endpoints - A REST API route at
/wp-json/oembed/1.0/embed - Rewrite rules for
/embed/endpoints on every post - A TinyMCE plugin for the classic editor
That’s a lot of infrastructure for a feature that amounts to “other WordPress sites can show a card with your post title.”
Why should you care?
Extra HTTP request on every page. The wp-embed.min.js file loads on every frontend page regardless of whether your content is embedded anywhere. It’s a small file, but the HTTP request itself costs time — especially on mobile where connection latency is higher.
Head section bloat. The two oEmbed discovery tags in your advertise your embed endpoints to the world. They add markup to every page and tell scrapers exactly where to find structured data about your content.
Username disclosure. Here’s the security angle most guides miss: the oEmbed JSON endpoint (/wp-json/oembed/1.0/embed?url=...) returns an author_url field that contains your WordPress username in the URL slug — like yoursite.com/author/admin/. That’s valuable reconnaissance for brute force attackers.
Unnecessary REST API endpoints. The oEmbed routes add to your REST API surface area. Every additional endpoint is a potential attack vector, even if the risk is small.
You probably don’t embed other WordPress posts. YouTube embeds, Twitter embeds — those work through a different system and are NOT affected by disabling WordPress oEmbed. Only WordPress-to-WordPress embeds are affected.
The quick fix
Add this to your theme’s functions.php or site-specific plugin:
// Disable WordPress oEmbed provider functionality
add_action( 'init', function() {
// Remove the REST API endpoint
remove_action( 'rest_api_init', 'wp_oembed_register_route' );
// Turn off oEmbed auto discovery
add_filter( 'embed_oembed_discover', '__return_false' );
// Don't filter oEmbed results
remove_filter( 'oembed_dataparse', 'wp_filter_oembed_result', 10 );
// Remove oEmbed discovery links from head
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
// Remove oEmbed JavaScript from frontend and backend
remove_action( 'wp_head', 'wp_oembed_add_host_js' );
// Remove embed rewrite rules
add_filter( 'rewrite_rules_array', function( $rules ) {
foreach ( $rules as $rule => $rewrite ) {
if ( false !== strpos( $rewrite, 'embed=true' ) ) {
unset( $rules[$rule] );
}
}
return $rules;
});
// Remove TinyMCE embed plugin
add_filter( 'tiny_mce_plugins', function( $plugins ) {
return array_diff( $plugins, ['wpembed'] );
});
// Remove pre-oEmbed result filter
remove_filter( 'pre_oembed_result', 'wp_filter_pre_oembed_result', 10 );
}, 9999 );After adding this code, flush your rewrite rules by visiting Settings → Permalinks and clicking Save (no changes needed).
Critical clarification: This does NOT break YouTube, Vimeo, Twitter, or any other third-party embeds. Those use WordPress’s oEmbed consumer functionality, which is separate. You’re only disabling the WordPress-as-provider part.
The one-click solution
OvKit includes Disable oEmbed under Features → Performance. One toggle removes the JavaScript, discovery links, REST API endpoint, rewrite rules, and TinyMCE plugin. Third-party embeds (YouTube, Vimeo, etc.) continue working normally.
What happens after you fix this?
- One fewer JS file loading on every page
- Two fewer
tags in your - oEmbed REST endpoint removed — smaller API surface area
- Username no longer leaked via the oEmbed author_url field
- YouTube, Twitter, and other third-party embeds still work perfectly
FAQ
Will disabling oEmbed break my YouTube and Twitter embeds?
No. Third-party embeds (YouTube, Vimeo, Twitter, Instagram, Spotify, etc.) use WordPress’s oEmbed consumer functionality, which is completely separate from the provider functionality we’re disabling. Your existing embeds will continue to work normally.
Someone is already embedding my posts on their site — will this break those?
Existing embeds on other sites may continue to display from cache for a while. New embed attempts will stop working — the other site will show a plain URL or blockquote instead of the preview card. This is usually the desired behavior if you’re disabling the feature.
Does this affect the Gutenberg block editor’s embed blocks?
No. The Gutenberg embed blocks for YouTube, Twitter, and other services use the consumer side of oEmbed, which remains fully functional. The only thing affected is other WordPress sites’ ability to embed your content as preview cards.
Related reads: