How to Embed Tweets on a WordPress Site (3 Methods Compared)

WordPress powers over 40% of the web. If you are trying to embed tweets on your site, there is a good chance you are doing it on WordPress — and there is an equally good chance you have run into at least one of the problems that make it harder than it should be.

Twitter's native embed system changed significantly after the rebrand to X. WordPress's built-in oEmbed support broke for many users. Third-party plugins introduced their own compatibility issues. And the documentation for all three approaches is scattered across forum posts from different eras, most of which reference APIs that no longer exist.

This guide covers the three methods that actually work in 2026, when to use each one, and what to avoid.

Method 1 — WordPress Native oEmbed

WordPress has built-in support for embedding tweets by pasting a tweet URL directly into the block editor. In theory, you paste the URL on its own line, and WordPress automatically converts it into a rendered tweet embed.

How it works

Open the WordPress block editor (Gutenberg)
Paste a tweet URL on its own line — for example: https://x.com/username/status/123456789
WordPress should automatically convert it to an embedded tweet block

When it works

This method works reliably when:

You are using the Gutenberg block editor (not the Classic Editor)
Your WordPress installation is version 6.0 or later
The tweet is from a public account
Your hosting environment allows outbound API calls to x.com

When it breaks

After X replaced the Twitter API and embed infrastructure, many WordPress installations stopped rendering oEmbeds correctly. Common failure modes:

The URL just sits as plain text. WordPress sends an oEmbed request to x.com and gets no response. This happens when X's oEmbed endpoint is down, rate-limited, or when your host blocks outbound requests.

The embed renders initially but breaks on page load. The block editor shows a preview, but the published page shows a blank space or a loading spinner. This is usually a caching issue — your page cache stores the embed HTML, but the JavaScript that renders it does not load correctly on cache playback.

The embed works on desktop but not mobile. X's embed script sometimes fails to resize correctly in responsive WordPress themes, leaving a broken layout on smaller screens.

The honest assessment

Native oEmbed is the simplest method when it works. It requires no plugins, no code, and no third-party service. But it is also the most fragile — it depends on X's oEmbed endpoint being functional, which has been intermittently unreliable since the platform transition.

If you are embedding a single tweet in a blog post and it renders correctly, native oEmbed is fine. If you are embedding multiple tweets, building a testimonial section, or need reliable rendering for a high-traffic page, you need a different approach.

Method 2 — Manual Embed Code (HTML Block)

If oEmbed fails, you can manually grab the embed code from X and paste it into a Custom HTML block in WordPress.

How it works

Go to the tweet on x.com
Click the three-dot menu (···) on the tweet
Select "Embed post"
Copy the HTML code provided
In WordPress, add a "Custom HTML" block
Paste the embed code

The embed code looks something like this:

<blockquote class="twitter-tweet">
  <p lang="en" dir="ltr">The tweet text here</p>
  &mdash; Display Name (@username)
  <a href="https://twitter.com/username/status/123456789">March 30, 2026</a>
</blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

When to use this

Manual embed code is more reliable than oEmbed because it does not depend on WordPress's oEmbed proxy — it loads the tweet directly from X's embed script. If native oEmbed fails on your site, this is the fallback.

The problems with manual embeds

You need one HTML block per tweet. Embedding 10 tweets means 10 separate HTML blocks, each with its own script tag. This is tedious to build and difficult to maintain.

The script tag loads multiple times. Each embed includes <script async src="https://platform.twitter.com/widgets.js">. If you embed 10 tweets, the browser loads this script 10 times (though it is cached after the first load, the initial parse still happens). On page-speed-sensitive sites, this adds measurable load time.

No curation or layout control. Each tweet renders as a standalone block. There is no carousel view, no wall view, no way to control the visual layout beyond stacking them vertically. If you want a grid or horizontal scroll, you are writing custom CSS.

Maintenance is manual. If a tweet gets deleted, your embed breaks — and you will not know until someone reports it or you happen to check. There is no monitoring, no fallback, no automatic handling of removed content.

The honest assessment

Manual embed code is the most reliable way to embed a single tweet on WordPress. It is not a practical method for embedding multiple tweets, building a testimonial section, or maintaining embeds over time.

Method 3 — Third-Party Embed Walls

The third approach is to use a service that fetches tweets, lets you curate them, and gives you a single embed code that renders a complete wall or carousel on your WordPress page.

How it works with LaunchWall

Paste the URL of a post that received replies you want to feature
LaunchWall fetches all public replies
Select the specific replies you want to display
Publish the wall and copy the embed code
In WordPress, add a Custom HTML block and paste the embed code

The result is a single iframe that renders a styled wall or carousel of curated tweets — with real usernames, real profile photos, and clickable links to the original posts.

Why this method exists

The first two methods work for embedding individual tweets. They do not work for the use case that most SaaS founders, marketers, and content creators actually need: a curated collection of specific tweets displayed as social proof.

If you are trying to build a testimonial section from your best X replies, a hero-adjacent social proof carousel, or an in-content wall of user reactions, you need something that handles:

Fetching replies from a specific post
Selecting which ones to display
Rendering them as a cohesive visual unit
Loading via a single, lightweight embed
Surviving if individual tweets get deleted (the wall caches the content)

Neither oEmbed nor manual embed code handles any of these requirements.

WordPress-specific implementation

In WordPress, the embed code goes into a Custom HTML block — the same mechanism as Method 2, but with a single embed instead of 10+ separate ones.

For the Gutenberg editor:

Add a new block where you want the wall to appear
Select "Custom HTML"
Paste the iframe embed code from LaunchWall
Preview the page to confirm rendering

For page builders (Elementor, Divi, Beaver Builder):

Use the HTML/Code widget or module
Paste the iframe code
Set the width to 100% for responsive behavior

For Classic Editor users:

Switch to the "Text" tab (not "Visual")
Paste the embed code at the desired position
Switch back to "Visual" to confirm it renders

Performance considerations

A single iframe embed loads one external resource. Compare this to 10 manual tweet embeds, each loading X's widget script independently. The iframe approach is lighter, faster, and produces a better Lighthouse score — which matters both for user experience and for Google's page experience ranking signals.

Which Method Should You Use?

Embedding a single tweet in a blog post: Use native oEmbed first. If it fails, use manual embed code.

Embedding 3+ tweets as a testimonial section: Use a third-party wall. The manual approach is too fragile and too slow to load.

Building a social proof carousel for your landing page: Use a wall with carousel display mode. Neither oEmbed nor manual embeds support carousel layouts.

Adding tweet testimonials to your pricing page or sign-up page: Use a wall. You need the curation, layout control, and loading performance that native methods do not provide.

For a broader comparison of tweet embedding methods across all platforms — not just WordPress — see how to embed tweets on your website.

Common WordPress-Specific Issues

Caching plugins break tweet embeds

WP Super Cache, W3 Total Cache, and WP Rocket can all interfere with tweet embeds by caching the page HTML before X's widget script has finished rendering. The result: visitors see an empty blockquote or a loading spinner instead of a rendered tweet.

Fix: Exclude pages with tweet embeds from full-page caching, or use an iframe-based embed (Method 3), which is unaffected by WordPress caching because the content loads inside the iframe independently.

Security plugins block external scripts

WordFence, Sucuri, and similar security plugins sometimes block platform.twitter.com/widgets.js as an external script. This silently breaks Methods 1 and 2.

Fix: Whitelist the X widget script in your security plugin's settings, or use an iframe embed that does not require the script to load on your domain.

Responsive breakpoints

X's native embed script does not handle responsive width elegantly in all WordPress themes. Tweets may overflow their container on mobile or leave large whitespace margins on tablet.

Fix: Wrap manual embeds in a container div with max-width: 100%; overflow: hidden;. Or use an iframe-based wall that handles responsive behavior internally.

The WordPress Recommendation

For most WordPress users who want tweet-based social proof on their site — whether it is a testimonial section, a social proof carousel, or a wall of launch reactions — the iframe approach is the right choice. It avoids the fragility of native oEmbed, the performance penalty of multiple manual embeds, and the caching and security plugin conflicts that are unique to WordPress.

Set it up once, embed it once, and it works across every WordPress theme, page builder, and hosting environment without configuration.

Build your WordPress-ready tweet wall in minutes →