How to Embed a 3D Flipbook in a Substack Newsletter (Workarounds)

Substack's editor doesn't support arbitrary iframe embeds. That's a deliberate platform choice — Substack wants email-deliverable content that renders consistently across mail clients, and iframes break in most of them. So you can't paste a 3D flipbook embed directly into a Substack post and have it render inline. This catches a lot of newsletter authors off guard when they try to embed a portfolio piece, a digital lookbook, or a deep-dive supplementary document.

There's a workaround that works well in practice, and it doesn't require leaving Substack. Below is exactly what works, what doesn't, and how authors of Substack newsletters in the 1k-50k subscriber range are using i3dify 3D flipbooks alongside their posts. If you're on Ghost or Beehiiv instead, native iframe embedding works there — skip to the workaround section if you're specifically on Substack.

What Substack does and doesn't support

• ●Native iframe embeds: NOT supported in posts (security/email compatibility)
• ●Native video embeds (YouTube, Vimeo): supported, render via oEmbed
• ●Native tweet/X embeds: supported
• ●Custom HTML: NOT supported in the standard editor
• ●Image embeds with link wrappers: supported (this is the workaround vector)
• ●Buttons with custom URLs: supported (cleaner CTA option)

The constraint is clear: you cannot inline-render a 3D flipbook inside the Substack post body. What you CAN do is link to the externally-hosted 3D flipbook from inside the post, using either an image that opens the flipbook on click, or a Substack-native button. Both approaches work — most authors choose the image approach because it gives the reader a visual preview.

The 'cover image + link' workaround

Step 1: Create your 3D flipbook on i3dify. Upload your PDF, image set, or document. Pick the flipbook viewer type. Customize the cover, save the project. Copy the public URL.

Step 2: Take a screenshot of the flipbook's cover page (or use the auto-generated thumbnail i3dify creates in your dashboard). This becomes the inline image in your Substack post — it acts as a visual preview so readers know what they'll get when they click.

Step 3: In Substack's editor, insert the image. Click the image to expose the link-wrap option. Paste the i3dify flipbook URL as the link target. Readers tapping the image in the email or web post open the full 3D flipbook in a new tab. Mobile email clients render the image inline, the click opens the flipbook in their phone browser, the flipbook works.

When this matters more: paid-tier newsletters

If you run a paid Substack tier, the 3D flipbook becomes a paid-only deliverable: you set the flipbook's URL to password-protected (i3dify Pro feature), share the password only with paid subscribers via the Substack post, and the gated content becomes a perceptible upgrade reason for the paid tier. Authors using this pattern see 12-25% lift in free-to-paid conversion when the paid post includes a gated interactive piece.

The pattern works because Substack's native paid-content gate only hides text and images, not 'exclusive interactive experiences'. A password-gated 3D flipbook reads to readers as a different category of content than the paid post itself — something more substantial. The actual content can be the same depth as a normal paid post; the format is what shifts the perception.

What about embedding in the post body via screenshots-as-pages?

Some authors try to fake the flipbook experience by uploading 5-10 screenshots of the flipbook pages as inline images in the Substack post. This works visually but loses the reason readers engage with the flipbook in the first place — the flip animation, the swipe gesture, the sense of going through a document rather than scrolling past 10 images. Don't do this. The cover-image-plus-link approach is better; the screenshots-as-pages approach is worse than just linking out without a preview.

Beehiiv and Ghost: native iframe support

If you're considering switching from Substack to gain native embed support, both Beehiiv and Ghost(Pro) support iframe embeds in posts via their HTML/custom-HTML block. The migration cost is real (importing subscribers, redirecting URLs, redesigning the brand) — most authors don't switch just for embed support, but if you're already evaluating a switch, embed flexibility is a tier-2 reason that compounds with the tier-1 reasons (deliverability, monetization options, design flexibility).

When the workaround isn't enough

Two use cases where the cover-image-plus-link workaround fails: very short newsletter posts where the click-out friction matters (readers won't leave the email for a 30-second skim piece), and AMP-rendered email versions where even the image link can be stripped by aggressive AMP optimization. For the first case, just don't link out — keep short posts self-contained. For the second case, the inline image still renders even when the link is stripped, so the loss is just the click destination.