We’ve talked about SVG quite a bit here on CSS-Tricks, but one area we haven’t quite touched on is email. Now that browser support for SVG is all in the green, it would be easy to assume that we can start using SVG everywhere. However, if you’ve worked with email before, you may know that it often follows way behind the web as far as feature support. You know, kinda the way California looks at North Dakota with trends: just a few years behind. :)
This article takes a deep dive into four different ways SVG can be used, and compares support for those methods across several of the most popular email applications. Let’s see where we get the most support.
- SVG as Image Tag
- SVG as Inline HTML
- SVG as CSS Background Image
- SVG as Object Embed
- Bonus: SVG with JPG Fallback
SVG as Image Tag
Using SVG as a straight-up
tag is like placing any other image file onto a screen, except we’re referencing an SVG file instead something like a JPG or PNG:
<img src="my-image.svg" alt="A pair of flat black dice, one on 5 and one on 3">
Here’s the support for this technique:
AOL Web | Outlook 2013 | Outlook .com | Yahoo! | Mail (OSX) | Mail (iOS) | Gmail | Gmail (iOS) | Gmail (Android) | Android |
---|---|---|---|---|---|---|---|---|---|
Yes | No | Yes | Yes | Yes | Yes | No | No | Yes | No |
Total support: 60%
SVG as Inline HTML
In this test, we’re plucking the code for the SVG file right out of Illustrator and plopping it directly into the email’s HTML:
<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="-227 241 225.3 224.1" style="enable-background:new -227 241 225.3 224.1;" xml:space="preserve">
<path class="dice-1" d="M-132,241h-72.3c-12.4,0-22.6,10.2-22.6,22.6V336c0,12.4,10.2,22.6,22.6,22.6h72.3c12.4,0,22.6-10.2,22.6-22.6
v-72.3C-109.4,251.2-119.6,241-132,241z M-195.3,340.5c-7.5,0-13.6-6.1-13.6-13.6c0-7.5,6.1-13.6,13.6-13.6
c7.5,0,13.6,6.1,13.6,13.6C-181.8,334.4-187.9,340.5-195.3,340.5z M-195.3,286.2c-7.5,0-13.6-6.1-13.6-13.6
c0-7.5,6.1-13.6,13.6-13.6c7.5,0,13.6,6.1,13.6,13.6C-181.8,280.1-187.9,286.2-195.3,286.2z M-168.2,313.3
c-7.5,0-13.6-6.1-13.6-13.6c0-7.5,6.1-13.6,13.6-13.6s13.6,6.1,13.6,13.6C-154.7,307.3-160.7,313.3-168.2,313.3z M-141.1,340.5
c-7.5,0-13.6-6.1-13.6-13.6c0-7.5,6.1-13.6,13.6-13.6c7.5,0,13.6,6.1,13.6,13.6C-127.5,334.4-133.6,340.5-141.1,340.5z
M-141.1,286.2c-7.5,0-13.6-6.1-13.6-13.6c0-7.5,6.1-13.6,13.6-13.6c7.5,0,13.6,6.1,13.6,13.6C-127.5,280.1-133.6,286.2-141.1,286.2
z"/>
<path class="dice-2" d="M-24.3,347.5h-72.3c-12.4,0-22.6,10.2-22.6,22.6v72.3c0,12.4,10.2,22.6,22.6,22.6h72.3
c12.4,0,22.6-10.2,22.6-22.6v-72.3C-1.7,357.7-11.9,347.5-24.3,347.5z M-87.6,447c-7.5,0-13.6-6.1-13.6-13.6
c0-7.5,6.1-13.6,13.6-13.6c7.5,0,13.6,6.1,13.6,13.6C-74.1,441-80.1,447-87.6,447z M-60.5,419.9c-7.5,0-13.6-6.1-13.6-13.6
c0-7.5,6.1-13.6,13.6-13.6s13.6,6.1,13.6,13.6C-46.9,413.8-53,419.9-60.5,419.9z M-33.4,392.8c-7.5,0-13.6-6.1-13.6-13.6
s6.1-13.6,13.6-13.6s13.6,6.1,13.6,13.6S-25.9,392.8-33.4,392.8z"/>
</svg>
The support is a lot less than I expected:
AOL Web | Outlook 2013 | Outlook.com | Yahoo! | Mail (OSX) | Mail (iOS) | Gmail | Gmail (iOS) | Gmail (Android) | Android |
---|---|---|---|---|---|---|---|---|---|
No | No | No | No | Yes | Yes | No | No | No | Yes* |
Total support: 25% (counting Android as partial support)
You might have noticed that I assigned class names for each path. If you were hoping the CSS properties for SVG are also supported for those email clients that recognize inline SVG, well, you’re in luck. They are, across the board.
fill
Mail (OSX) | Mail (iOS) | Android |
---|---|---|
Yes | Yes | Yes |
stroke
Mail (OSX) | Mail (iOS) | Android |
---|---|---|
Yes | Yes | Yes |
SVG as CSS background Image
We can use SVG as a background image in CSS:
.my-element {
background-image: url("my-image.svg");
background-repeat: no-repeat;
}
AOL Web | Outlook 2013 | Outlook.com | Yahoo! | Mail (OSX) | Mail (iOS) | Gmail | Gmail (iOS) | Gmail (Android) | Android |
---|---|---|---|---|---|---|---|---|---|
Yes | No | No | Yes | Yes | Yes | No | No | No | No |
Total support: 40%
Note that some email applications are known to strip CSS from the document . In these cases, it is a best practice to inline our styles in addition to including them in the
.
Also, CSS backgrounds are a bit unpredictable if we’re dealing with a responsive design. Keeping the width and height proportional to each other would be tricky, and probably more hassle than it’s worth.
SVG as Object Embed
Embedding SVG as an <object>
is a lot like embedding a media file, like audio or video. The benefit—aside from retaining some styling control with CSS—is that a fallback image can be set where SVG is not supported:
AOL Web | Outlook 2013 | Outlook.com | Yahoo! | Mail (OSX) | Mail (iOS) | Gmail | Gmail (iOS) | Gmail (Android) | Android |
---|---|---|---|---|---|---|---|---|---|
No | No | Yes* | Yes* | Yes† | Yes | No | No | Yes | Yes |
† overflows the container
Total support: 55% (with partial support for Mail OSX)
Image Tag with CSS Hack
Update: The following hack was intended to exploit Gmail's lack of support for CSS contained in the document but that is no longer the case as of September 2016. The support table at the end of the article has also been updated to reflect this change.
Update 2 (Dec. 7, 2022): Both the <img>
and <picture>
elements support the srcset
attribute, making it possible to define image fallbacks without the CSS hiding method in the following section. In other words, we can specify multiple files in <img>
and let the email client pick its poison:
<img src="my-image.jpg"
alt="A pair of flat black dice, one on 5 and one on 3"
srcset="my-image.svg"
/>
Thanks to Viktor Mukhachev for the tip!
The results here aren’t very encouraging. I mean, the the best support is 60% and that's kinda crappy. But, what if we tried combining a couple of different techniques to get something provides us better support?
Here’s the trick. First, we’ll add one image tag for the SVG and one for a backup JPG:
<!-- Image: SVG -->
<img src="my-image.svg" alt="A pair of flat black dice, one on 5 and one on 3" role="img">
<!-- Image: JPG -->
<img src="my-image.jpg" alt="A pair of flat black dice, one on 5 and one on 3">
That role="img">
is there to account for a bug that prevents VoiceOver to properly identify SVG as an image, as explained over at MDN.
If we were to stay with this, we would have a situation where some email applications display two images and others display one with a broken image symbol. Yuck.
Let’s hide that JPG for the email applications that do support SVG. No, Modernizr does not work for email, but we do know that a few applications ignore any CSS that is in the document . We can use that to our advantage by adding a classname to the JPG image element and hiding it with CSS:
<!-- Image: SVG -->
<img src="my-image.svg" alt="A pair of flat black dice, one on 5 and one on 3" role="img">
<!-- Image: JPG -->
<img class="no-showy" src="my-image.jpg" alt="A pair of flat black dice, one on 5 and one on 3">
/* Hide this everywhere, except for those that can’t read this code */
.no-showy {
display: none;
}
Now we’re on a roll! We have accomplished the feat of hiding the JPG in all email applications, except Gmail. If we stop here, however, here’s how Gmail renders the code:

Ack, so close. Now we need to hide that broken image tag where the SVG should go. Let’s do a couple of things:
- Add a height and width of zero to the SVG
- Add a classname to the SVG that resizes it
In other words:
<!-- Image: SVG -->
<img class="showy" src="my-image.svg" width="0" height="0" alt="A pair of flat black dice, one on 5 and one on 3" role="img">
<!-- Image: JPG -->
<img class="no-showy" src="my-image.jpg" alt="A pair of flat black dice, one on 5 and one on 3">
Removing the width and height of the SVG inline has the same effect as hiding it. Then, we use the CSS document hack by adding a class that changes those dimensions back to a full-size image for the email applications that support SVG:
/* Resize an element that has a width and height of zero to full size */
.showy {
height: 100% !important;
width: 100% !important;
}
/* Hide this everywhere, except for those that can’t read this code */
.no-showy {
display: none;
}
Our support starts to look a heck of a lot better:
AOL Web | Outlook 2013 | Outlook.com | Yahoo! | Mail (OSX) | Mail (iOS) | Gmail | Gmail (iOS) | Gmail (Android) | Android |
---|---|---|---|---|---|---|---|---|---|
Yes | Yes* | Yes | Yes | Yes | Yes | No | No | No | Yes |
So, so, so close! We have full support for many clients, a responsible fallback for another, and unfortunately no support in Gmail which is a significant slice of market share.
My biggest takeaway...
...is that email is still in the Wild West of front-end development. I would personally feel like using SVG is a gamble, particularly if it's known that your subscribers rely on Gmail.
That said, knowing your audience is likely the determining factor for whether SVG can and should be used in email. For example, a developer of iOS apps who knows that customers consume email on an OSX or iOS device might feel really good about using SVG. Many email marketing providers (like MailChimp and Campaign Monitor) make this information easy to find with analytics. Campaign Monitor also has a pretty handy report on the popularity and market share of email applications that is worth checking out.
Is there any particular reason why email clients have always been so far behind? Really hard to code? Would have to rewrite everything? People just accept it? A layout other than tables would cause more problems that it solves? I never understood this. (never looked into it either…)
For stand-alone email clients, I think a lot of it is just development resources not being there.
For in-browser email, it’s a mix of performance, UX, and security concerns. In order to provide a fast and consistent UI for an entire email conversation, Gmail doesn’t create separate
<iframe>
s for each message, it just inserts the (modified) HTML into the main page. To avoid messing up the rest of the page, it therefore strips out all global styles and anything that could affect the overall page layout, or anything with security issues.Not sure why they don’t like an
<img src="*.svg">
, though. That has neither layout nor security issues (or at least, no more so than any other image type).Gmail is webmail, there is no technical reason SVG shouldn’t work here. This seems to me that Google has ulterior motives for not allowing SVG…
SVG can call its own external resources, which can call their own external resources, etc. I can see where that might be a security concern, and nobody wants to be the next “Outlook attachments” poster child.
For some reason, Microsoft decided to use the MS Word HTML rendering engine in Outlook 2007 to 2013 (desktop version) – this was even worse than the IE5/IE6 rendering engine which I believe was used in Outlook 2000, 2002 and 2003! As most large corporate businesses force their staff to use a version of desktop Outlook that hasn’t been updated in years, email is stuck in this hell of being held back in worse-than-IE6 web.
Luckily now mobiles and webmail is prevailing which is bringing in these standards, and the likes of MS Office 365 subscriptions are replacing old and crusty versions of MS Office (and with it Outlook) in the workplace. So things are on the up.
It’ll take a good few years to get there, but email will eventually catch up with the modern web.
Great resource, even with the rather disappointing results for browser support.
However, I’m worried about your fallback strategy. I’d assume that most email clients will end up downloading both image files. Since one of the key benefits of SVG is usually file size, I’m not sure how often there would be a benefit relative to using the raster (PNG/JPEG) fallback alone.
The fallback has very nice support and where it didn’t work (a few outlying instances) it showed nothing rather than displaying the images twice.
Still, you’re absolutely correct that the work to create the fallback comes with little benefit, considering the reasons we may want to use SVG are not fully possible or supported in email. You won’t be catching me using SVG in an important email campaign anytime soon. :)
Did you happen to test base 64 encoded data URI’s? I remember once reading something about browser support being slightly different when using data URI SVG, not sure if it’s still relevant today or when used in an email client but might be interesting to check out as another CSS background solution.
This post is relevant in terms of older browser support for SVG using data URI. Wonder if the same could be applied to email clients?
Sure did! The results were surprisingly the same. I used a base 64 encoder on the web, it spit out some awful-looking code and turned up working as well as referencing the image file itself.
Great question!
As a technical research this is interesting.
But “a developer of iOS apps who knows that customers consume email on an OSX or iOS device” misses “and is not using Gmail” so even this target group is hardly worth the effort IMHO.
Email still is and probably will for time be a very stripped down version using very old tech. And as hard as it is to test properly I would recommend to use the simplest stuff possible which is known to work everywhere.
Actually personally I would use text mail and no HTML at all ;)
Here’s an update to your code to remove the broken image symbol in outlook
Nice article, by the way, Geoff… Keep trying to love email – the challenge makes it fun (kinda).
Cheers,
Gavin
Oh nice! Totally forgot about the conditional statements as a means for targeting Outlook–nice addition!
I just don’t get it why people keep pushing with technologies and E-Mails. So far there is not standard guiding anything in the email … Look here is how to create responsive emails … but it wont work on X and Y and Z … This is how to use video background in email … but it only works on X … Finally, SVG in emails wow!
Until emails have a document that vendors follow I don’t think it worth wasting time with all that.
thunderbird?
Who would ever use that?!
Just kidding! It’s included in the comprehensive Litmus test:
https://litmus.com/checklist/public/2d3f533#thunderbirdlatest
Nice support for inline SVG!
Thanks for the tips! Great stuff. Love SVG :-)
Doesn’t native android (above 2.3) support SVG (or so I read)? Initially you have it as “no”, but at the end changed it to “yes”.