Ask a nerd: Can I use SVG images in emails?

This article is part of a series that answers newsletter questions we often hear from users. Send us any questions you'd like us to answer!

SVG files are not images themselves. Instead, SVGs are instructions on how to make an image. A banner image like the one above (without the underlying text) weighs in at around 240 KB as a JPG image, with an approximation of every pixel spelled out in numbers. The same image as an SVG file, with the curves and colors detailed in XML text? About 20 KB, less than a tenth as large. And since they’re instructions that tell the computer to “make envelope blue” and “have corners of this radius,” the resulting images can scale as needed, looking as crisp on an iPhone as on a 27” display.

Sounds like a good solution for sending images in size-constrained, responsive email messages.

If only it were so easy. SVG support in email apps was always spotty. But by late 2025, most major email apps blocked these types of files from rendering in email messages due to security issues and a surge in malicious SVGs. You can still email one as an attachment, with the potential hit to deliverability that all attachments carry, and without the stylistic advantage of crisply-rendered, scalable graphics.

Better stick to JPG and PNG images, instead.

But why?

The image that does it all

The image formats we accept as standard today—JPEG with their lossy compressed bitmap images, PNG with their support for transparency, animated GIFs, and SVG for scalable vectors—took a while to become the dominant format. BMP and GIF images were most common in the early ‘90s, alongside the lossless, oversized TIFF files typically from scanned documents. It took enough time for patents to expire before today’s image standards solidified.

Vector graphics were more isolated, confined as they were to proprietary editing software such as Adobe Illustrator’s .ai files. Their appeal was obvious, though, and every major tech player seemingly tried their hand at making a new vector standard. Microsoft, HP, and Autodesk promoted VML for Vector Markup Language. Boeing and Xerox proposed WebCGM for Computer Graphic Metafiles. Adobe, IBM, Netscape, and Sun put their weight behind PGML for Precision Graphics Markup Language. They and three other standards competed to be the W3C standard for vector graphics.

The W3C in 1998, instead, took XKCD 927 seriously and decided to start from scratch. And as so many design-by-committee projects, as the X.400 project attests, that often ends up with a bloated everything-goes standard. “Some committee members were highly passionate about particular features,” said then-Adobe team member and SVG spec editor Jon Ferraiolo. “So it was sometimes necessary to say ‘yes’ to everyone’s pet features to keep spec marching forward.”

Three years of discussion and building later, and SVG became the official vector standard of the web, with XML-formatted instructions to render graphics.

But not just vector graphics. SVG supports everything. Animations, “because the W3C wanted synchronized multimedia and because CSS animations weren’t proposed until 2007.” Fonts, “because SVG needed reliable high-quality fonts, and interoperable web fonts that all browsers would implement only gained momentum in the last couple of years.” Filters, clipping paths, and more, “because certain committee member(s) really wanted these features, and it was easier to say yes than no,” recalled Ferraiolo. Clickable links, even. Adobe’s interview about SVG’s history even refers to the standard as one for “interactive, animated two-dimensional vector graphics,” when most people would only think of using SVG for the final two words of that definition.

And here there be dragons.

When images can tell your computer what to do

Given enough time, hackers seem to find vulnerabilities in everything. JPG and PNG images can include malicious data in their headers and metadata, or could be a script or program only disguised to appear as an image. Rare, but possible. Files with executable code, though, such as Microsoft Word files with potentially-malicious macros, or PDF files with embedded JavaScript, can prove even more dangerous. You get them in an email, double-click to open without thinking, and the world comes crashing down.

Interactive emails in any form comes with their own set of issues. Dynamic emails break the static, record-in-time feature of email that most rely on for record-keeping (one of the many reasons Google’s AMP never took off). But they also are ripe for vulnerabilities, both thanks to their code and the potential to load new, more dangerous code long after the email message was originally delivered.

SVGs, with their JavaScript code, remote content, and more in their everything-goes spec, are far more problematic. One could build an entire website, encode it in base64, and remotely load it inside an SVG file—something it’s unlikely a good actor would consider worth the trouble but that would give a rogue actor a field day.

No wonder Cloudflare named them “the hacker’s canvas” when outlining some of the most malicious SVG files in emails that would render a full webpage inside the image. They’d appear to be a legitimate login page but would instead steal credentials — with remotely loaded malicious code, so the SVG would make it through first-pass security scans only to do its worst later when opened in the office. Not exactly what the SVG creators had in mind when implementing every company’s favorite features.

Render an SVG live in an email, and you risk not simply displaying an image but rendering an entire small app that can dupe readers while skirting by spam filters. SVG itself was already difficult to support with its over-bloated spec. And after one phishing case too many, it made more sense to block it by default than to risk one more bad SVG-driven attack.

It’s best to assume that you cannot reliably use SVG images in email.

Gmail has never fully supported SVG files. Outlook on desktop, mobile, and web apps stopped rendering SVG files as of late 2025. Apple Mail and Thunderbird are among the holdouts that still display SVG images in email messages. All of them can still send and receive SVG files, they just come in as attachments rather than being embedded in your email—good for collaborating on an SVG image, bad for using SVG files for your logo or banner images.

There is one extremely niche exception: BIMI logos. Gmail, with early support for the new brand indicators that are coming to email, says that “logos used with BIMI must be in Scalable Vector Graphics (SVG) file format,” with such detailed specifications for said SVG files that you literally have to create the SVG logo in Adobe Illustrator, then hand-edit the exported text. Not exactly your average SVG-in-email use case.

What to use instead of SVG in email?

Your best SVG alternative for email is either PNG files for images with transparency, or JPG files otherwise.

There is no direct alternative to SVG, no other vector image format without interactivity and security issues that you could include in emails instead. And while it’s possible to create an image in CSS and HTML, it’s hardly worth the trouble, not when Gmail (for only one example) strips out a wide range of CSS features and clips emails when their body is larger than 102kb.

If you really want to use SVG files in the email apps like Apple Mail that do support them, you do have one option: Use both SVG and another image format as a fallback. Add your graphics in an <picture> block, with a <source> block for your SVG image, and a fallback <img> block for your PNG or JPG file, as outlined in this guide.

That’d work, but odds are you’d be better off exporting your SVG files in PNG format and shelving, for now, your dreams of scalable images in email.