Why Your App Won’t “Just Embed the Video”

The history of embeds (YouTube, Rumble, Loom), why many platforms block them, and what the biggest apps do instead

If you’ve ever tried to drop a YouTube, Rumble, or Loom link into a product and expected a clean inline player—only to get a plain link or a bland preview card—you’ve run into one of the web’s oldest tensions:

Embeds are great UX… and a security/privacy/business headache.

This article breaks down (1) how embeds evolved, (2) why platforms increasingly don’t support them, (3) what YouTube/Rumble/Loom are actually providing under the hood, and (4) the patterns major “domain apps” use when they refuse full embeds but still want a good experience.

1) The early web: “embedded objects” and the chaos era

Embedding started as “drop this foreign object into my page”:

<object>, <embed>, and later Flash players were common.
The host page often had little control over what the embedded thing did.
The embedded thing often had more power than you’d like (tracking, popups, sketchy scripts).

This era produced a predictable backlash: platforms learned that letting arbitrary third-party content render inside your UI is a security and trust risk.

2) The modern embed: iframes + standards (and guardrails)

The iframe became the “safe-ish” container

Iframes isolate third-party content into a different browsing context. But “isolated” doesn’t mean “harmless.” Clickjacking, tracking, weird navigation behaviors, and cookie issues still exist.

Modern web security tools explicitly focus on controlling embedding:

X-Frame-Options can block a page from being framed to prevent clickjacking.
CSP frame-ancestors is the more flexible replacement: it lets a site specify exactly who is allowed to embed it.

A second big shift: URL→Embed protocols (oEmbed)

Instead of pasting raw <iframe> code, platforms increasingly want you to paste a URL and let them “resolve” it into a safe embed (or a preview).

oEmbed defines how a consumer can turn a URL into structured embed data.

This is a key reason many apps say “we don’t support embed codes”—they support URL-based embedding via an allowlisted resolver.

3) YouTube: the canonical “approved embed” model

YouTube is the reference point for how embeds “should” work on the web:

YouTube provides an official iframe player API explicitly intended for embedding and control via JavaScript.
They also document player parameters and constraints for embedded players.

Important nuance: YouTube embeds are not “free-form.” YouTube can restrict embedding at the content level (e.g., a video owner can disable embedding), and the embed operates inside YouTube’s policy + tracking + availability constraints.

So YouTube “supports embeds,” but in a controlled, policy-driven way.

4) Rumble: embeds exist, but interoperability is messier

Rumble supports iframe-based embedding in practice (you’ll commonly see rumble.com/embed/... URLs in the wild), but the friction is often in platform support rather than Rumble itself.

Two reasons Rumble links often fail to embed inside other apps:

Allowlists / resolver support: many platforms only embed providers they’ve explicitly approved (more on that below).
Robots / fetch restrictions: embed resolvers (like Iframely/Embedly) may be blocked from fetching provider pages, which breaks automatic embedding. For example, Iframely shows errors when it can’t fetch Rumble URLs.

Rumble also appears in oEmbed provider lists (as discussed in dev communities), which is how platforms can resolve a Rumble URL into embed HTML—if they choose to integrate it.

5) Loom: “embeds when possible,” plus graceful fallbacks

Loom is a great case study because they explicitly acknowledge a truth most teams discover the hard way:

Some apps block embeds.

Loom’s own documentation:

says you can embed videos in many platforms, but some websites and platforms block embedding, and recommends using GIF thumbnails as a widely compatible fallback.
provides a straightforward iframe embed code workflow for web pages.
also offers an Embed SDK so apps can convert Loom links into embedded players more reliably.

This is the modern reality: a provider doesn’t just ship “an embed”—they ship a spectrum:

automatic embed integrations,
a sanctioned iframe player,
and a fallback artifact (GIF thumbnail) when embeds aren’t allowed.

6) So why do apps not support embeds?

Here are the “real” reasons—what product and security teams debate internally.

A) Security: clickjacking + injection risk

If you allow arbitrary iframes, attackers can:

visually trick users into clicking on hidden UI (clickjacking),
attempt navigation abuse,
exploit gaps in your sandboxing.

This is why the web has explicit anti-embedding controls like X-Frame-Options and CSP frame-ancestors.

B) Privacy: embeds leak viewer data

When your app loads a third-party embed, the third party can receive:

viewer IP address,
user agent,
referrer signals,
and potentially cookie-linked identity.

Notion is unusually explicit about this: it notes that embedded content providers may receive viewer IP addresses (and uses a third-party service to power many embeds).

C) Performance and reliability

Embeds are often heavyweight:

they add network requests,
execute scripts,
and can degrade page performance unpredictably.

D) Moderation and brand safety

If your product is a “knowledge” surface, you’re responsible for:

what appears inline,
whether it’s appropriate,
and whether it can be abused.

A raw iframe is basically: “render this foreign UI inside mine.” That’s hard to moderate.

E) Business control / platform policy

Some apps don’t want to become a perfect distribution channel for any random provider:

they keep a curated list,
or they downgrade unknown providers to a preview card.

7) How major “domain apps” handle embeds (patterns that work)

Pattern 1: Allowlisted URL embeds (no raw HTML)

Medium is a clean example:

You paste a URL; Medium converts it to an embed if supported.
Medium explicitly says embedding with embed code is not supported and that embeds are handled via Embed.ly (which supports hundreds of providers).

This gives Medium:

centralized control,
consistent rendering,
fewer security surprises.

Pattern 2: Unfurls / preview cards instead of players

Slack mostly optimizes for link previews rather than full embeds, and it uses allowlists:

Some audio/video services won’t expand unless they’re approved.
Slack also provides a developer path for richer unfurls, but still controlled.

This is “embed-lite”: users get context without running a third-party app inside Slack.

Pattern 3: Third-party embed resolvers (Iframely / Embedly)

Notion uses Iframely to support a large number of embed domains.
Loom mentions integrations with Embedly and Iframely to embed Loom content across many platforms.

Resolvers are popular because they:

normalize provider quirks,
supply oEmbed/open-graph parsing,
and give platforms a single integration surface.

Pattern 4: Fallback artifacts

When embeds are blocked, the “universal” fallback is:

a thumbnail card,
sometimes a GIF preview (Loom explicitly recommends this for environments that won’t embed the player).

This preserves UX while avoiding iframe execution.

8) Practical takeaway: “Not supporting embeds” is usually a design choice, not a missing feature

When an app says “we don’t support embeds,” it usually means:

We don’t allow arbitrary HTML/iframes
We might support:
- URL-based embeds for allowlisted providers
- preview cards for everyone else
- or “open in new tab” with a strong visual preview

That’s the compromise modern platforms converge on:
make content feel native without running the whole internet inside your product.