Native videos in emails without a hassle are easier to implement than you think
“No other marketing medium can communicate as quickly and effectively as video.” Neil Patel, Co-Founder at Neil Patel Digital.
Imagine you are an email marketer creating campaigns where video plays a crucial role in your brand’s communication, whether it’s product feature demos, instructional guides, presentations, or customer success stories. Video is integral to showcasing your product’s value and driving sales. While other communication channels let you easily share videos with your audience, email presents significant obstacles.
Due to the technical complexities of embedding video in emails, you are constantly faced with a difficult choice:
- use a static image linked to the video and sacrifice some engagement;
- embed the video natively, coding it manually with workarounds, juggling with fallback versions and having no guarantee that it will function correctly in the subscriber's email client.
Video is most useful when seeing something in motion explains it better than a screenshot can. For example, if we are promoting a website builder feature, a short video showing the feature in action can communicate the experience much faster than several screenshots. I also find video useful for product launches, tutorials, customer stories, and demos. It gives the email a more personal feel and can help people understand the product before they click through.
(Source: Reddit)
This is a challenge that plagues many email marketers, and questions about how to embed videos directly into emails more conveniently and effectively are becoming increasingly common. That is exactly what we will explore in this article. We will dive into the main reasons why embedding full video files in emails is so difficult, look at how the industry is trying to solve this problem, and examine Stripo’s own solutions designed to make marketers' lives easier.
Why native videos are so rare in email newsletters
It is worth noting that there are valid reasons why email clients struggle to handle true native video. A combination of significant factors is at play, each deserving individual consideration.
-
Lack of official support by email clients
The primary reason is the near-total lack of support for native video across email clients. This stems from the varying rendering approaches used by different clients. For instance, Outlook has historically relied on the Microsoft Word rendering engine to display emails, making it technically impossible to embed native video. In contrast, Apple Mail has utilized WebKit-based rendering with HTML5 video support from the start, enabling seamless native video playback.
The biggest issue is that email clients do not all handle video in the same way. A video that works perfectly in one inbox may not play at all in another.
There are also performance concerns. Large video files can make an email heavy, slow to load, and unpleasant on mobile connections. Autoplay can also be annoying, especially when someone opens an email in a public place.
Another issue is recipient expectation. People are used to clicking a video and getting a proper player, so trying to force a full video experience inside an email can sometimes create more friction than value.
Monica Panait,
To give you a clearer picture of the current state of video support across email clients, here is the situation:
|
Email client |
Native video in emails support |
|
Apple Mail |
Yes, but it depends on the version (can differ across macOS, iOS, and the overall Apple Mail version) |
|
Samsung Mail |
Yes |
|
Gmail |
No |
|
Outlook for Windows |
No |
|
Outlook.com |
No |
|
Outlook on mobile |
No |
|
Yahoo Mail |
No |
As a result, if you manage to embed a native video inside your email, the only recipients that will see it are those using Apple Mail and Samsung Mail. The other ones will see a fallback version (if you also implemented it) or will not see anything at all.
Roughly speaking, Apple's mail apps will play video, and Gmail, Outlook, and Yahoo will not. That covers most of what a marketer needs to know, because the practical answer doesn't change either way. Build the version that works everywhere, and treat playback as a bonus for whoever happens to get it.
The more useful advice is to stop reading industry averages and look at your own list. Where your subscribers actually read is the only number that matters here, and it varies enormously by audience. A B2B list that opens at a desk during work hours is a very different situation from a consumer list on phones. And be careful with your open data generally, because Apple's privacy changes have made open rates far less trustworthy than they used to be.
-
Video file size
Another significant factor is the file size of the video. When every second of email loading time counts, large video files can drastically slow down load speeds. This explains not only why email clients have been slow to implement native video support but also why marketers often avoid this approach; after all, it is better to simply include a link to the video than to risk slow loading times for the entire email just for the sake of the potential engagement offered by native video.
The biggest mistake I see is treating an email like a webpage. Email has a much more restricted environment, and marketers cannot assume that something that works in a browser will work in every inbox.
There is also the issue of loading time. A large asset can hurt the experience before the recipient even gets to the message. On mobile, this becomes even more noticeable.
-
More implementation hassle
Beyond technical issues, the human factor shouldn't be overlooked. Many marketers want to avoid the extra workload associated with native video. If an email campaign requires native video, it means that, in addition to coding and testing the templates, teams must create fallback versions to ensure the content displays correctly if the recipient opens the email in a client that doesn't support native video.
Given how few email clients actually support native video, the question arises: why go through all this extra trouble when you could simply use an image with a link, an approach guaranteed to display correctly for everyone? Marketers prefer to avoid the hassle of native video and the need to juggle fallbacks, as these tasks consume time and energy that could be better spent on higher-priority objectives.
Email was never built to play video, and the inbox providers most of your subscribers use still strip it out. That means every video you put in an email has to be built twice, once as video and once as a still image that links out, and the still image is what the majority of your list will see. So you're really designing the fallback and hoping a slice of your audience gets the better version.
The second problem is weight. The workarounds people reach for, usually animated images, make the email heavy, and heavy emails get truncated or land in promotions. You can spend real production time on something most people never see, and slow down the email for everyone in the process.
Neal Schaffer,
How industry tries to solve the problem
Broadly speaking, there does not seem to be a solution to this problem. Marketers have grown accustomed to the fact that including video in an email usually means a GIF preview or simply a link to the video itself.
Major ESPs and other tools have made virtually no concrete progress toward supporting native video in emails, and we can’t blame them for that. As it’s all likely due to the aforementioned limitations in video support. Consequently, for many email creation tools, video functionality is limited to a standard image with a link to the video's landing page, though users can often customize how the video preview appears within the email.
For most campaigns, I prefer using a video thumbnail with a play button that links to the video on a landing page or video platform. It is simple, reliable, and gives the marketer much more control.
Native HTML5 video inside the email can work in some email clients, but I would treat it as an enhancement rather than the main strategy. It is not reliable enough across the entire inbox ecosystem.
Monica Panait,
The closest thing to a solution right now is a category of standalone tools: you upload your video, the tool generates a ready-made HTML snippet with the fallback built in, and you paste that snippet into your email's code. It works, but it also means leaving your email builder entirely for this one element, and if anything in that snippet gets touched afterward (a stray edit, a template migration, an ESP re-export), the fallback can silently break with no warning.
Some of these tools go a step further, allowing marketers to manually configure the fallback before the code is generated (e.g., selecting an image, adding a CTA button, etc.).
These tools also attempt to address the issue of native video file size by automatically adjusting quality based on the specific email client; however, despite this convenience, you have no control over the final quality the recipient actually sees, as you can’t choose how exactly your video will be compressed. The algorithm may compress your video too much to cater to recipients’ email opening environment and internet speed, so in the end they’ll see a blurry mess instead of your initial video.
Major players like Mailchimp and Benchmark Email offer direct integrations with such tools, but that is where efforts to make life easier for marketers generally end.
The blocker isn't really technology; it's that the biggest inbox providers have no particular reason to move. Previous attempts to make email do more have struggled because they asked senders to jump through separate hoops for each provider, and most marketing teams don't have the time or the appetite for that.
What would help most marketers isn't a new standard anyway. It's their email builder handling the fallback automatically, so you add a video once, and the tool produces the right version for every inbox without anyone touching code. That removes the production tax, which is the actual reason most teams skip video in email rather than any philosophical objection to it.
And the question worth asking first is whether video in the email is the goal at all, or whether the click to somewhere you can measure properly is worth more.
Neal Schaffer,
Stripo solution
At Stripo, we certainly can’t fix the lack of native video support across email clients. However, we can definitely eliminate the headache of the complex, time-consuming process of adding native videos to emails.
Until now, our Video block offered standard functionality: you simply added a video link, and the block automatically fetched the title, description, and thumbnail. You could also fine-tune the visual style by customizing "Play" buttons, custom previews, and more. However, the result was essentially a static image that redirected the recipient to the video page when clicked.
Now, we are adding hassle-free support for native video within templates using a familiar Video block. You can upload a video directly into the block, and the system will automatically generate a fallback GIF for email clients that do not support native video playback. The whole feature revolves around making it as easy as possible to add native videos and eliminating the need to tinker under the hood of the email.
You can tweak settings to make video autoplay once the email is opened, loop it, turn sound on and off for the whole video, what fallback GIF to use, where to start GIF animation from, and much more. These settings go on top of the familiar settings of the Video block to adjust padding, alignment, and more.
Unlike the copy-paste workflows we described earlier, none of this leaves the builder. Because the fallback GIF settings (which frame to start from, autoplay, sound) are exposed to you directly, you control exactly what non-native clients will see, instead of leaving that to an automatic quality adjustment you can't inspect.
Now, adding native videos to your templates looks like this: add a Video block to your template, upload the video inside the block, tweak necessary settings, and you are done.
All code-related things are done behind the scenes, and you’ll receive a template that will show the corresponding video version:
- for iOS, macOS, Samsung, AMP Gmail, and AMP Yahoo, you will get native MP4 video playback;
- for macOS Outlook, HTML Gmail, and HTML Yahoo, an animated GIF with autoplay will be displayed;
- for the Windows Outlook app and Office 365, an animated GIF with a play button will be used.
In the past, all of this had to be coded and tested manually; now, you are just a couple of clicks away from fully native video, complete with all the necessary fallback versions that we have already accounted for and tested for you.
Wrapping up
As previously mentioned, email was not designed to handle full-fledged video. Issues such as inconsistent rendering, slow load times, and the technical hassle of embedding native video mean that very few email clients fully support the feature.
While the global landscape regarding native video support is unlikely to change anytime soon, we can still address specific challenges within the current limitations: namely, the coding process and the need to constantly account for fallbacks across various email clients.
Most marketers should not have to understand the technical differences between email clients, video formats, fallbacks, compression, and rendering rules. The email platform should handle most of that in the background.
The other area I would like to see improve is analytics. It would be useful to connect video engagement with the actual business outcome, so marketers can see whether watching the video helped someone become a lead or customer.
Tom Bukevicius,
Our Video block upgrade is a small step toward making life easier for marketers. There is no coding involved and no need to create separate fallback versions; everything is handled for you, so all you have to do is upload the video. And who knows? Perhaps simplifying the process will encourage the email community to voice a stronger demand for native video, eventually leading to better support from email clients.
0 comments