What Is FxEmbed? FixupX, FxTwitter, Social Embeds, RSS, and APIs Explained

FxEmbed is best known for one tiny URL trick: replace x.com with fixupx.com, paste the result into Discord or Telegram, and the post often appears with a much better preview.

That description is accurate, but it is no longer complete.

FxEmbed has grown into an open-source layer that can turn social posts into rich link previews, normalized JSON, RSS or Atom feeds, direct media links, and automation-friendly data. It sits between social platforms and the clients that need to display or process their content.

Quick answer: FxEmbed is an open-source social content normalization and unfurling service. Its public services include FxTwitter, FixupX, and FxBluesky. A changed URL can improve a post preview; the same project also exposes APIs, feeds, media routes, translation options, and self-hosting tools.

What is FxEmbed?

FxEmbed is the project behind several related domains:

The common interaction is deliberately simple:

https://x.com/username/status/123
                    ↓
https://fixupx.com/username/status/123

For an older Twitter URL:

https://twitter.com/username/status/123
                    ↓
https://fxtwitter.com/username/status/123

And for Bluesky:

https://bsky.app/profile/user.bsky.social/post/abc
                    ↓
https://fxbsky.app/profile/user.bsky.social/post/abc

There is no Discord bot to install and no browser extension required. A sender changes the URL, and the chat client does the rest.

The official getting-started guide describes richer support for videos, GIFs, multiple images, polls, quoted posts, external media, expanded t.co links, and tracking-parameter removal.

Why does a replacement URL improve the preview?

When a Discord, Telegram, Slack, or messaging client sees a link, it usually does not render the original website as a full application. Instead, a crawler requests the URL and reads metadata such as:

<meta property="og:title" content="...">
<meta property="og:description" content="...">
<meta property="og:image" content="...">
<meta property="og:video" content="...">
<meta name="twitter:card" content="...">

This process is often called link unfurling. The quality of the preview depends on the metadata the source returns, the media formats the client accepts, and the client-specific rules applied to that metadata.

Native social-platform pages do not always return the best representation for third-party preview crawlers. Videos may become static thumbnails. A four-image post may show only one image. A quoted post can lose its media. A poll can disappear entirely.

FxEmbed acts as a compatibility layer:

X or Bluesky post
        ↓
FxEmbed retrieves and parses the content
        ↓
Text, media, quote, poll, and card data are normalized
        ↓
Client-appropriate Open Graph and embed metadata are generated
        ↓
Discord, Telegram, or another client renders the preview

This is why describing FxEmbed as an Open Graph proxy is useful, but still slightly incomplete. It is also a parser, media router, feed generator, and API surface.

FxEmbed is not an iframe

FxEmbed does not simply put the original social post inside an <iframe>.

For a preview request, its server-side code can inspect the host, path, query parameters, and requesting user agent. A crawler such as Discord's can receive embed metadata designed for that client. A normal human clicking the same URL can be redirected to the original post or to a configured alternative frontend.

That distinction matters:

• The sender does not need to install anything.
• The recipient does not need to install anything.
• The chat client remains responsible for rendering the final card.
• FxEmbed can optimize metadata without reproducing the entire social network interface.

This is a classic server-side unfurl service: a small HTTP interface that makes incompatible systems work together.

What does FxEmbed improve?

The exact result still depends on the destination client, but the official feature comparison shows why people use FxEmbed instead of a native X preview.

The important phrase is client-dependent. FxEmbed can return better metadata, but it cannot force every app to render every Open Graph feature identically.

The URL is also the interface

One of FxEmbed's best design decisions is that many features require no dashboard and no SDK. The URL itself selects the behavior.

Direct media with d.

Add the d. subdomain to route directly to a post's media:

https://d.fxtwitter.com/user/status/123456789
https://d.fixupx.com/user/status/123456789
https://d.fxbsky.app/profile/user.bsky.social/post/abc123

File extensions can express the same intent:

https://fxtwitter.com/user/status/123456789.mp4
https://fixupx.com/user/status/123456789.jpg

This is useful for bots, download flows, media-processing jobs, and agents that need the asset rather than a preview wrapper. The behavior is documented in the direct-media guide.

Text only with t.

The t. subdomain removes photos and video from the embed:

https://t.fixupx.com/user/status/123456789

That can be helpful for low-bandwidth clients, text archives, moderation pipelines, or an LLM workflow that wants the post body without media noise. See the text-only documentation.

Mosaic with m.

The m. subdomain combines multiple images from a post into a single composite image:

https://m.fixupx.com/user/status/123456789

This provides a practical fallback for clients that cannot display a native multi-image gallery. FxEmbed notes that mosaic is already the default on many platforms other than Discord. The mosaic guide explains the route.

Other documented modifiers cover gallery mode, media selection, translation, Telegram Instant View, and legacy embeds. Together they make FxEmbed feel less like a website and more like a compact URL protocol.

RSS and Atom turn social accounts into automation inputs

FxEmbed can expose X/Twitter and Bluesky profiles as RSS 2.0 or Atom feeds.

For X/Twitter:

https://fxtwitter.com/openai/feed.xml
https://fxtwitter.com/openai/feed.atom.xml
https://fxtwitter.com/openai/media.xml
https://fxtwitter.com/openai/media.atom.xml

For Bluesky:

https://fxbsky.app/profile/user.bsky.social/feed.xml
https://fxbsky.app/profile/user.bsky.social/feed.atom.xml

Optional parameters include item count, replies, sensitive-content filtering, and requested translation. The documentation currently allows count values from 1 to 100 and explicitly warns that automatic translation availability may vary.

The feed feature unlocks workflows that do not need a custom social API integration:

X or Bluesky account
        ↓
FxEmbed RSS or Atom
        ↓
Feed reader, n8n, or scheduled worker
        ↓
Summarization, classification, alerts, or archiving
        ↓
Slack, email, Telegram, or a database

This is one reason FxEmbed deserves to be discussed alongside developer infrastructure rather than only Discord utilities.

The API is the most important part for developers

FxEmbed exposes public API endpoints at:

https://api.fxtwitter.com
https://api.fxbsky.app

The current recommended version uses /2/. Legacy v1 compatibility remains available, but the official docs say it does not receive the newest features.

The API surface goes far beyond fetching a single post. The current reference includes operations for posts, unrolled threads, conversations, profiles, user timelines, media, followers, following, search, typeahead, and trends. Bluesky exposes a similar set where the underlying platform supports it.

The project deliberately aligns response shapes across providers where practical. That means an application can aim for a common internal model:

type SocialPost = {
  id: string;
  text: string;
  author: {
    handle: string;
    name?: string;
  };
  media?: Array<{
    type: "photo" | "video" | "gif";
    url: string;
  }>;
  quote?: SocialPost;
};

The official API documentation currently lists a v2 limit of 1,000 requests per minute per IP, uses cursor-based pagination for larger collections, and publishes runtime OpenAPI specifications:

https://api.fxtwitter.com/2/openapi.json
https://api.fxbsky.app/2/openapi.json

Those specifications make it straightforward to generate a client, create an MCP tool, or give a coding agent a machine-readable description of the API.

Why FxEmbed is useful for AI agents

Social websites are awkward sources for agents. A browser session may face JavaScript-heavy pages, authentication prompts, rate limits, consent dialogs, or content that is difficult to reduce to clean text.

FxEmbed creates a shorter path:

User supplies an X link
        ↓
Agent extracts the post identifier
        ↓
FxTwitter API returns structured JSON
        ↓
Agent reads text, author, media, quote, poll, and metrics
        ↓
Agent summarizes, verifies, classifies, or stores the result

That makes FxEmbed a practical X-to-LLM adapter for prototypes and personal automation. It can reduce the need to ask a general browser agent to visually navigate a social page just to extract a post.

It does not eliminate browser infrastructure. Tools such as Browser Use, Browserbase, and Hyperbrowser remain valuable when an agent must log in, click, upload, or operate a full web application. Our browser agent infrastructure comparison explains that layer in more detail.

The distinction is simple:

• Use a normalized content API when the information already has a clean endpoint.
• Use browser automation when the task genuinely requires a browser session.

The same division of labor applies to coding agents. Claude Code, Codex CLI, or OpenCode can consume an OpenAPI spec and build a small social-research tool without learning every platform's page structure.

Bluesky support shows the normalization strategy

FxBluesky is not just a different logo on the same redirect. It has its own API base and operations for posts, profiles, threads, conversations, media, likes, search, trends, followers, and following.

The interesting part is the attempt to make provider responses similar enough for multi-network applications. A developer should still preserve provider-specific fields, but a shared core can make a multi-source tool much easier to maintain.

That is the beginning of a broader product category:

Social content normalization: one application-facing model over several incompatible social sources.

Is FxEmbed expanding beyond X and Bluesky?

The public FAQ still presents X/Twitter and Bluesky as the supported embed sources. That is the safe description of the product users can rely on today.

However, the deployment documentation reveals a broader engineering direction. Its configuration supports a TikTok provider realm, and the credentials guide documents Instagram and Threads proxy behavior, including authenticated routes that are unavailable on logged-out surfaces.

The right conclusion is not that every provider has identical public-service coverage. It is that FxEmbed's architecture is becoming more provider-oriented and more capable of supporting a wider social layer.

This distinction matters because support can exist at several levels:

1. A provider adapter exists in the repository.
2. A self-hosted deployment can configure it.
3. A public domain exposes it.
4. The project documents and supports it as a stable user-facing service.

Only the fourth level should be treated as a broad product promise.

Architecture and technical stack

FxEmbed's workload is a good match for edge computing. Most requests are short-lived HTTP reads: inspect a URL, obtain upstream data, normalize it, and return metadata, JSON, XML, or a redirect.

At the time of our review, the main repository used:

• TypeScript
• Hono
• Zod and Zod OpenAPI
• i18next
• Cloudflare Workers
• esbuild
• Vitest

The request path looks roughly like this:

Client, crawler, bot, or agent
              ↓
       Cloudflare Worker
              ↓
  Provider-specific retrieval
              ↓
     Normalization and routing
              ↓
┌─────────┬──────────┬───────────┬──────────────┐
│ Embed   │ JSON API │ RSS/Atom  │ Direct media │
└─────────┴──────────┴───────────┴──────────────┘

A single codebase can route different domains to different provider realms and can change behavior based on subdomain, path, query, or user agent. That is an elegant fit for Workers' global HTTP execution model.

Self-hosting and white-label deployment

FxEmbed is released under the MIT License. When checked on August 31, 2026, its public GitHub repository had roughly 5,000 stars, 210 forks, and more than 4,000 commits.

The self-hosting guide recommends Cloudflare Workers and uses a conventional workflow:

git clone https://github.com/FxEmbed/FxEmbed.git
cd FxEmbed
npm install

cp wrangler.example.toml wrangler.toml
cp .env.example .env

npm run deploy

An optional branding.json can customize zones with a name, domain list, provider, favicon, redirect, colors, and activity icons. This makes private domains and white-label instances possible.

But “easy to deploy” should not be confused with “maintenance free.” A serious deployment may also need credential rotation, monitoring, upstream failure handling, and careful secret storage.

Privacy and redirect behavior

FxEmbed's privacy FAQ says the public service avoids collecting unnecessary data. It reports runtime errors, limited information needed to diagnose account-proxy failures, and anonymous operational analytics. It says it does not collect who posted or clicked a link and does not sell the data.

The service also removes X tracking parameters such as ?s= and &t= from links.

For people who do not want clicks to return to X directly, FxEmbed also documents custom redirects to alternative frontends. A self-hosted instance can control the bare-domain and click-through destinations in its branding configuration.

Privacy still needs to be evaluated in context. FxEmbed is an intermediary: the service receives the URL request, and the underlying social platform remains the original data source. Organizations with strict data-handling requirements should self-host or review the public service's current policy before routing sensitive internal workflows through it.

The main risk is upstream dependency

FxEmbed's edge code can be lightweight while its data access remains operationally difficult.

Potential failure modes include:

• X or another provider changes an internal API.
• Guest access or authentication behavior changes.
• A credential hits a rate limit or checkpoint.
• A session cookie expires.
• A post is private, age-restricted, deleted, or region-limited.
• Media URLs or formats change.
• A client such as Discord changes its unfurl rules.

The self-hosting documentation makes this trade-off visible. Some higher-coverage routes rely on authenticated account credentials. The Instagram guidance, for example, warns that sessions are not permanent and recommends using accounts that operators are willing to lose.

So the operational reality is:

The Worker is easy to deploy. Reliable access to changing social platforms can be hard to maintain.

That also means FxEmbed should not automatically be treated as a contractual replacement for an official platform API. It is an excellent open-source compatibility layer, but production teams should design fallbacks, caching, observability, and provider-specific failure handling.

FxEmbed versus vxTwitter

FxTwitter and vxTwitter are different projects despite their similar names and URL-replacement workflows.

Common FxEmbed domains include:

fxtwitter.com
fixupx.com
fxbsky.app

Common vxTwitter domains include:

vxtwitter.com
fixvx.com

FxEmbed's current differentiators include its broader URL-modifier system, native multi-image handling, quoted media, translation support, external media, gallery and direct-media modes, Telegram Instant View, RSS/Atom feeds, and a more extensive public API.

The best choice can still depend on the client and the type of post. The important point is not to assume the two domain families are aliases for the same service.

The bigger product idea: social data for agents

FxEmbed demonstrates a strong infrastructure pattern: do not recreate the content; make difficult content easier for software to consume.

The human interface is tiny:

x.com → fixupx.com

The utility behind it is much larger:

Human     → better link preview
Developer → normalized JSON
Automation→ RSS or Atom
Bot       → direct media
AI agent  → structured social context
Operator  → open-source self-hosting

That pattern points toward a broader category: social data infrastructure for agents. A future service could normalize X, Bluesky, Reddit, Threads, TikTok, YouTube, and other networks behind one agent-friendly schema, with provenance, permissions, caching, and consistent error semantics.

Traditional social-media APIs are usually organized around each platform. An agent-first product would instead be organized around jobs:

• Get a post and its full thread.
• Resolve quotes and media.
• Search recent discussion about an entity.
• Watch an account or topic.
• Return citations and source URLs.
• Deliver the result as JSON, RSS, an MCP tool, or a webhook.

FxEmbed does not provide every part of that future system, but it shows how much value can come from a small, composable compatibility layer.

Frequently asked questions

Is FxEmbed an official X or Bluesky product?

No. It is an independent open-source project that retrieves and transforms public social content for better embeds, feeds, and APIs.

Is FixupX the same as FxEmbed?

FixupX is one public service powered by the FxEmbed project. It handles x.com-style links. FxTwitter handles twitter.com-style links, and FxBluesky handles Bluesky links.

Does FxEmbed require a Discord bot?

No. Changing the domain in the shared link is usually enough because Discord's own crawler requests the FxEmbed URL.

Can FxEmbed return JSON?

Yes. FxTwitter and FxBluesky expose versioned public API endpoints, and current OpenAPI specifications are available for v2.

Can FxEmbed create RSS feeds from X accounts?

Yes. It exposes RSS and Atom profile feeds, including media-only variants, with optional query parameters.

Can I self-host FxEmbed?

Yes. The project is MIT-licensed and provides a Cloudflare Workers deployment guide. Full coverage may require provider credentials and ongoing maintenance.

Is FxEmbed reliable enough for production?

It can be useful in production, but reliability is constrained by upstream platforms and unofficial or authenticated access paths. Use caching, monitoring, fallbacks, and explicit error handling rather than assuming official-API availability guarantees.

Final assessment

FxEmbed began with an unusually effective interface: change a few characters in a social URL and get a better embed.

Its current value is broader. The same project can serve humans, chat clients, bots, feed readers, applications, and AI agents through different representations of the same post.

The most accurate 2026 definition is:

FxEmbed is an open-source social media embed, normalization, and data-delivery layer.

That makes it worth studying not only as a Discord utility, but as a compact example of modern agent-ready infrastructure: a small interface, several composable outputs, and a difficult upstream integration hidden behind a simpler contract.

Official resources

• FxEmbed documentation
• FxEmbed API overview
• FxEmbed RSS and Atom guide
• FxEmbed self-hosting guide
• FxEmbed source code on GitHub

Last verified: August 31, 2026. Public services, rate limits, provider access, and upstream behavior can change.