WordPress Embeds (oEmbed) Not Showing: Fixes for YouTube, X, Instagram

This article is a localized edition of the Japanese original. Read the Japanese original

In WordPress, when you paste a URL from YouTube or a similar service on its own line in a post, or enter it in an "Embed" block, the video or post is displayed in place. This mechanism is called oEmbed. WordPress asks the other service (the provider) for embed HTML and displays it.

This article covers the causes of, and fixes for, cases where a URL is not turned into an embed and stays a plain link, or the editor says "Sorry, this content could not be embedded." Everything here was checked on WordPress 7.1.3 in a test environment as of October 2026.

What to check first

The WP-CLI wp embed command is handy for narrowing down the cause. It shows what the server gets when it asks the provider directly.

# Is a provider registered for the URL?
wp embed provider match https://www.youtube.com/watch?v=XXXXXXXXXXX

# Can the embed HTML be fetched? (test without the cache)
wp embed fetch https://www.youtube.com/watch?v=XXXXXXXXXXX --skip-cache

# Show the provider's raw response (to isolate network problems)
wp embed fetch https://www.youtube.com/watch?v=XXXXXXXXXXX --raw

Narrow down the cause from the results as follows.

Cause 1: A failed result is still cached

WordPress caches embed results. For URLs inside posts, they are stored in post metadata (_oembed_… and _oembed_time_…); everything else is stored in posts of the oembed_cache type.

When fetching fails, the failure itself is saved as {{unknown}}, and from then on the URL is shown as a link. That is why a temporary network problem can leave a URL as a link even after the problem is gone.

To clear the cache for one post, pass its post ID.

# Clear the embed cache for post 123
wp embed cache clear 123

# Fetch and cache the embeds for post 123 again
wp embed cache trigger 123

To clear the cache for the whole site at once, work on the database directly. Back up the database before you start.

wp db export before-oembed-clear.sql

# Delete embed caches stored in post metadata
wp db query "DELETE FROM $(wp db prefix)postmeta WHERE meta_key LIKE '\_oembed\_%'"

# Delete embed caches not tied to posts (oembed_cache)
wp post delete $(wp post list --post_type=oembed_cache --format=ids) --force

# Flush the object cache if you use one
wp cache flush

wp post meta delete cannot take a wildcard meta key (such as _oembed_*). To delete them in bulk, use SQL LIKE as shown above. If there are no oembed_cache posts, wp post delete ends by printing its usage, which is harmless.

After clearing the cache, also purge your page cache plugin and CDN caches before checking the page.

Cause 2: Automatic embedding has been disabled

Turning a URL pasted on its own line into an embed is done by WP_Embed::autoembed, registered on the the_content filter. If a theme's functions.php or a plugin contains something like the following, this processing stops.

<?php
// Code that stops automatic embedding (remove it if you find it)
remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 );

You can check the current state with WP-CLI.

wp eval 'var_dump( has_filter( "the_content", array( $GLOBALS["wp_embed"], "autoembed" ) ) );'

If it prints int(8), it is active. If it prints bool(false), something has removed it. Search the theme and plugin files for autoembed to find the code.

grep -rn "autoembed" wp-content/themes wp-content/plugins wp-content/mu-plugins

Cause 3: X (formerly Twitter) x.com URLs

As of October 2026, WordPress 7.1.3 core registers providers for twitter.com URLs but none for x.com URLs.

• URLs in the form https://twitter.com/username/status/… are embedded as is
• URLs in the form https://x.com/username/status/… do not match the core list. WordPress then looks for a provider using information in the page, but for safety it keeps only some of the HTML from providers found this way, so the parts needed to show the post are stripped and it stays a link

There are two fixes.

• Change x.com in the pasted URL to twitter.com
• Register x.com URLs with the same provider core uses for twitter.com

For the second option, save the following code as wp-content/mu-plugins/x-embed.php (create the mu-plugins directory if it does not exist).

<?php
/**
 * Plugin Name: Enable x.com embeds
 */
add_action(
	'init',
	function (): void {
		wp_oembed_add_provider( '#https?://(www\.)?x\.com/\w{1,15}/status(es)?/.*#i', 'https://publish.twitter.com/oembed', true );
	}
);

In the test environment, an x.com post stayed a link before this code was added and became an embed afterwards. For posts already cached as a link, clear the cache as described in Cause 1.

Cause 4: Instagram and Facebook are no longer supported by core

Instagram and Facebook embeds were removed from core's provider list in WordPress 5.5.2. Pasting their URLs no longer produces an embed. This is not a WordPress settings or cache problem.

If you want to show them, use one of the following.

• On the Instagram website, get the embed code from the post's menu and paste it into a "Custom HTML" block
• Use a plugin that supports Instagram or Facebook embeds (some require setting up a Meta developer app or an access token)

Cause 5: The server cannot reach the provider, or the response is slow

With oEmbed, the WordPress server asks the provider, not the visitor's browser. Fetching fails in cases such as:

• The server's firewall or the hosting provider's settings restrict outbound HTTPS
• The server's DNS settings are wrong and it cannot resolve the provider's host name
• The provider responds slowly

If wp embed fetch … --raw fails, check whether the server can reach the same URL directly with curl.

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' 'https://www.youtube.com/oembed?url=https://www.youtube.com/watch?v=XXXXXXXXXXX&format=json'

If a response comes back but takes a long time, you can extend the timeout for oEmbed requests only. WordPress's default HTTP timeout is 5 seconds. Instead of http_request_timeout, which affects every request the site makes, use the oEmbed-specific oembed_remote_get_args filter.

<?php
/**
 * Plugin Name: oEmbed timeout
 * Description: Extends the oEmbed fetch timeout from the default 5 seconds to 15 seconds.
 */
add_filter(
	'oembed_remote_get_args',
	function ( $args, $url ) {
		$args['timeout'] = 15;
		return $args;
	},
	10,
	2
);

Cause 6: A CSP is blocking the content

If your site sends a Content Security Policy (CSP) header, the browser blocks the iframe or external scripts an embed uses when their domains are not allowed. The telltale sign is that the server can fetch the embed HTML, but the browser shows a blank area.

Open the console in your browser's developer tools and look for errors saying a Content Security Policy was violated. Add the domains shown in those errors to the CSP's frame-src or script-src. In the test environment, YouTube embeds used an iframe from https://www.youtube.com, and X posts used the script https://platform.x.com/widgets.js.

If your site does not use a CSP yet, we do not recommend adding one only for this, because it affects other features too. For how to set up a CSP, see "How to set up a Content Security Policy (CSP) in WordPress".

Summary

• Use wp embed fetch and wp embed provider match first to see whether the server can fetch the embed
• Failures are cached as {{unknown}}. Clear them with wp embed cache clear POST_ID or in bulk with SQL LIKE (wp post meta delete does not accept wildcards)
• remove_filter( 'the_content', array( $GLOBALS['wp_embed'], 'autoembed' ), 8 ) stops automatic embedding. Check that no such code is left
• x.com URLs are not registered in core, so change them to twitter.com or add a provider
• Instagram and Facebook were dropped from core support in WordPress 5.5.2
• For slow responses use oembed_remote_get_args; if the browser shows a blank area, check the CSP

Related articles:

• How to fix Content Security Policy (CSP) errors in WordPress

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)