If you have tried embedding a tweet on your website, in a Discord channel, or on a WordPress page in the last two years and watched it fail — show nothing, render a generic X logo, or load a blank iframe — you are not imagining things. Twitter embeds are broken. Not temporarily. Not as a bug that is being fixed. They broke deliberately, and the situation has only partially recovered.
This is the full story of what happened, why it happened, and what it means if you rely on tweet content anywhere outside of X itself.
How Tweet Embeds Used to Work
For over a decade, embedding a tweet was one of the simplest things you could do on the internet.
Twitter provided three mechanisms that made it work:
Open Graph metadata. Every tweet URL served OG meta tags — og:title, og:description, og:image — that allowed any platform (Discord, Slack, Facebook, LinkedIn, iMessage) to generate a rich preview when someone shared a tweet link. This happened automatically, no API key required.
The oEmbed API. Twitter offered a public oEmbed endpoint that returned structured HTML for any tweet. Content management systems like WordPress, Ghost, Medium, and Squarespace used this to auto-embed tweets when a user pasted a URL. No authentication, no rate limits for normal usage, completely free.
widgets.js. Twitter's JavaScript widget library. You pasted a <blockquote> tag and a <script> tag into your HTML, and widgets.js rendered the tweet as an interactive card — profile photo, username, tweet text, engagement counts, and a clickable link back to the original post. It was the standard way to embed tweets on websites, and it mostly just worked.
This system was free, reliable, and universal. It was also built on the assumption that Twitter wanted its content distributed across the internet. That assumption changed.
What Changed — The Timeline
February 2023: The Announcement
Twitter announces the end of free API access. The existing free tier that powered countless integrations, bots, and third-party apps would be shut down and replaced with paid tiers.
April 2023: Free API Access Killed
The free tier is officially removed. The cheapest paid tier starts at $100 per month for basic access. Enterprise tiers run into the tens of thousands. Overnight, thousands of apps, bots, and services that relied on free API access stop working or shut down entirely.
The embed system (oEmbed, widgets.js) was technically separate from the general API — but this was the signal that Twitter's new ownership viewed external access to Twitter data as something to be monetized, not given away.
Mid-2023: The X Rebrand
Twitter rebrands to X. The domain changes from twitter.com to x.com. This is not just a cosmetic change — it breaks things.
OG metadata structures change. URL patterns change. Applications that hardcoded twitter.com patterns for auto-embedding — including WordPress core — suddenly have to deal with a new domain. Some handle the redirect gracefully. Many do not.
The widgets.js script remains hosted at platform.twitter.com, but the inconsistency between old and new URLs creates a steady stream of edge-case failures across every platform that embeds tweets.
Late 2023 to 2024: The Cascade of Breakage
This is the period where most people noticed the problem. Discord previews for tweet URLs become unreliable — sometimes showing the full tweet card, sometimes showing a generic X logo, sometimes showing nothing. WordPress stops auto-embedding x.com URLs in several versions. Forum platforms like XenForo lose timeline embed functionality entirely. Websites using widgets.js report intermittent load failures and blank iframes.
The root cause is not a single bug. It is a combination of factors: X increasingly requires authentication for page requests, which blocks the crawlers that platforms like Discord and WordPress use to fetch preview data. OG metadata becomes inconsistent — sometimes present, sometimes stripped, sometimes returning generic fallback data. The old twitter.com URLs redirect to x.com, but the redirect chain does not always preserve the metadata that embedding systems need.
2025 to 2026: Partial Stabilization
The situation has improved somewhat. X's OG metadata is more consistent than it was during the chaotic 2023-2024 period. Discord previews work more often than they fail. widgets.js still functions in most cases.
But "more often than they fail" is not the same as "reliable." Native tweet embeds in 2026 remain fundamentally less dependable than they were before 2023. If you are building a professional website and relying on native X embeds for your social proof section, you are building on a foundation that has already proven it can break without warning.
For a practical walkthrough of how embedding works today, see how to embed tweets on your website.
Why This Happened
This was not a bug. It was a business decision.
Elon Musk's acquisition of Twitter came with a clear strategic shift: keep users on the platform, monetize data access, and reduce the server costs associated with external crawlers and bots consuming Twitter's infrastructure.
Free API access let anyone pull tweet data for any purpose. That was generous — and expensive to maintain. Cutting free access and charging for the API was a straightforward monetization move.
Restricting OG metadata and requiring authentication for page requests serves a different purpose: it makes tweet content less useful outside of X. If a tweet URL does not generate a rich preview on Discord, the person sharing it has more reason to post the content directly on X instead. If widgets.js becomes unreliable, website owners have more reason to link to X rather than embed content away from it.
Whether or not you agree with this strategy, understanding the motivation matters. This is not a technical problem that X's engineering team is working to fix. It is a deliberate architectural decision that aligns with the platform's business interests. The breakage is a feature, not a bug — at least from X's perspective.
What Actually Broke — Platform by Platform
Discord
Tweet URLs in Discord used to consistently render as rich preview cards showing the author's profile photo, display name, and full tweet text. After X's changes, these previews became unreliable. Some tweets show full previews. Some show a generic X logo with no tweet-specific content. Some show nothing at all — just a plain URL with no embed card.
The inconsistency is the problem. You cannot predict which tweets will preview correctly and which will not. For a detailed breakdown, see how to embed a tweet in Discord.
WordPress
WordPress had built-in oEmbed support for Twitter. You pasted a tweet URL into the editor, and WordPress automatically converted it to an embedded tweet card. After the rebrand, x.com URLs stopped auto-embedding in several WordPress versions. Only twitter.com URLs worked — and even those became unreliable as the redirect behavior changed.
WordPress eventually updated its oEmbed providers list, but the experience remains inconsistent depending on your WordPress version, theme, and caching setup.
Forums (XenForo, phpBB, Discourse)
Forum platforms were hit hard. XenForo's timeline embed feature — which let users embed entire Twitter timelines in forum posts — broke completely. Individual tweet embeds became inconsistent. Forum administrators reported that embedded tweets would load on one page refresh and show a blank box on the next.
Websites Using widgets.js
The core embed script still loads from platform.twitter.com, but its behavior has become less predictable. Websites report intermittent blank iframes, delayed rendering, and inconsistent styling across browsers. On pages with multiple embedded tweets, the failure rate compounds — if widgets.js has a momentary issue loading, every embed on the page goes blank simultaneously.
The performance cost has also increased. Each embedded tweet requires loading X's script, making network requests to X's servers, and rendering in an iframe. On a landing page with ten embedded tweets, this adds meaningful load time and creates ten separate points of failure.
Email Clients
Email was never a great environment for tweet embeds — most email clients strip JavaScript entirely, which means widgets.js has never worked in email. But the OG metadata changes made the fallback behavior worse too. Email clients that used to show a basic preview card when a tweet URL was included now often show nothing or a generic link.
For strategies that work in email, see the dedicated guide on embedding tweets in email campaigns.
The Workaround Ecosystem
The breakage spawned an entire ecosystem of third-party tools designed to fix what X broke. These are worth knowing about — with a clear understanding of what they can and cannot do.
FixTweet / fxTwitter
The most popular workaround for Discord. Instead of sharing x.com/user/status/123, you share fxtwitter.com/user/status/123. FixTweet's servers fetch the tweet data and serve proper OG metadata that Discord can render as a rich preview.
It works well for its intended purpose: making tweet links look good in Discord and other chat platforms. But it is a third-party proxy. You are routing tweet content through someone else's infrastructure. That is fine for casual sharing in a Discord channel. It is not appropriate for a professional landing page or business website.
vxTwitter
Similar to FixTweet but uses the domain vxtwitter.com. Same concept, same trade-offs. Works for chat platforms. Not suitable for production websites.
Discord Bots (FixEmbed, BetterTwitFix)
These bots monitor your Discord server for tweet URLs, delete the original message (or suppress its embed), and re-post the content with a fixed preview. They solve the Discord preview problem within Discord — but only within servers where the bot is installed.
Browser Extensions
Several browser extensions intercept tweet URLs and replace them with FixTweet equivalents, or inject their own preview rendering. These solve the problem for individual users, but they do not help if you are trying to display tweet content to your website visitors.
The Common Limitation
All of these workarounds share the same constraint: they solve the sharing and previewing problem, but they do not solve the embedding problem. If you need tweet content on your website — on a landing page, in a testimonial section, as social proof — these tools do not help. They are built for chat platforms, not for production web pages.
What This Means for Businesses Using Tweet Testimonials
If your business uses tweet replies as testimonials — on a landing page, pricing page, or case study — the embed situation creates a real problem.
Native X embeds are unreliable. You cannot guarantee that the embed will render correctly for every visitor, on every browser, at every time of day. A landing page with broken social proof is worse than a landing page with no social proof at all.
Screenshots are unverifiable. The instinct when embeds break is to fall back to screenshots. But screenshot testimonials carry a different cost: visitors cannot verify them. Research from the Baymard Institute on e-commerce credibility consistently shows that unverifiable testimonials reduce trust rather than building it. A screenshot of a tweet is an assertion. A verifiable embed is evidence. For a deeper look at this, see why screenshot testimonials don't convert.
Manual HTML cards are unverifiable too. Building custom tweet card components in your HTML — with the user's avatar, handle, and quote hardcoded — gives you design control but the same credibility problem. The visitor cannot click through to verify the original post. It looks like marketing copy styled to resemble a tweet.
The gap this creates. There is a genuine need for a way to display tweet content on websites that is both reliable (does not depend on X's infrastructure rendering correctly) and verifiable (the visitor can confirm the testimonial is real). This is the specific problem that purpose-built tools solve — hosting the tweet content independently while maintaining a link back to the original post for verification.
LaunchWall does this by letting you paste a post URL, select the best replies, and generate an embeddable carousel that renders from its own infrastructure. No dependency on widgets.js. No blank iframes. The tweets display consistently, and each one links back to the original post on X so visitors can verify them.
That said, LaunchWall is one option. The important thing is understanding the constraint: if you need tweet testimonials on a professional website in 2026, you need a solution that does not depend on X's embed system working correctly. Because it does not — reliably.
For a full comparison of approaches, see how to fix X/Twitter embeds not working.
FAQ
Are X/Twitter embeds completely broken?
No. Native X embeds still work in many cases. widgets.js still loads, and many embedded tweets render correctly. The problem is consistency — embeds fail intermittently, and you cannot predict when or why. For a personal blog post, the occasional failure is acceptable. For a landing page where social proof directly impacts conversion, the unreliability is a real business risk.
Will X fix embedded tweets?
There is no indication that X considers this a problem to fix. The reduced reliability of external embeds is consistent with X's broader strategy of keeping content on its platform. X has not announced any plans to improve embed reliability, restore free API access, or make OG metadata more consistent for external platforms.
What is the most reliable way to show tweets on a website in 2026?
Use a tool that hosts the tweet content independently rather than depending on X's infrastructure. This means the tweet data is fetched once and stored, so your embed renders from your own (or the tool's) servers rather than making real-time requests to X. LaunchWall does this. There are other tools that take similar approaches. The key criterion is that the embed should not break if X changes something on their end.
Do FixTweet and vxTwitter work for websites?
No. FixTweet and vxTwitter are designed for chat platforms like Discord. They serve corrected OG metadata so that tweet links generate proper preview cards in chat. They do not provide an embed solution for websites. You cannot use a FixTweet URL in an iframe on your landing page and expect it to look professional or function correctly.
Can I just use screenshots instead of embeds?
You can, but you should not — at least not on pages where trust matters. Screenshot testimonials are not verifiable, which means they do not build the credibility that real social proof requires. Visitors have no way to confirm the screenshot is real, and increasingly, they assume it is not. See why screenshot testimonials don't convert for the full case against screenshots.
Is this just a Twitter/X problem or does it affect other platforms too?
The embed reliability problem is specific to X. Other platforms — YouTube, Instagram, TikTok — have their own embed systems with their own quirks, but none have undergone the same level of deliberate disruption. The X embed situation is unique because it resulted from a combination of an API access change, a domain migration, and a strategic decision to reduce external content distribution — all within a short period.
Skip the broken embed problem — build a tweet carousel that works everywhere