Background images in HTML email

Quick answer: Background images in HTML email work in most modern clients through a combination of the HTML background attribute and CSS shorthand, but classic Outlook for Windows ignores CSS backgrounds entirely and needs Microsoft’s VML code, while Gmail can get fussy about how you declare the image. Every reliable implementation needs three things layered together: the HTML background attribute for webmail, a VML block for classic Outlook, and a solid fallback bgcolor for when the image is blocked, stripped, or simply doesn’t load. That combination is what “bulletproof” actually means, and it still matters through at least 2029.

A designer sends you a hero. It’s gorgeous – some moody lifestyle photo, a headline sitting on top of it in a nice light font, a button. You build the email, you check it in Apple Mail and it’s perfect, you check it on your phone and it’s perfect, you fire a test into Gmail and it’s fine, you ship it, you make tea. Then a screenshot lands in Slack from somebody on the client side who still runs Outlook 2019 on a Windows machine in an office somewhere, and the background image is just… gone. Replaced by a flat grey rectangle with white text floating on it that you can barely read. That moment – the one where you stare at the screen and quietly question your career – is what this entire guide about background images in HTML email is built to prevent.

I’ve been coding emails for a long time and background images in HTML email are still one of the two or three things that catch people out the most, partly because the rules keep moving. The technique that worked in 2019 isn’t quite the technique you want in 2026, Gmail did something genuinely alarming in 2023 that half the tutorials online still describe as if it’s current (it isn’t – more on that in a minute), and the whole “Outlook is dying so you can stop caring” narrative is wrong in a way that’s going to cost people real money if they believe it. So this is the long version. Code included, the failure modes I keep seeing in code reviews included, an honest section on tools and what they cost now, and a forward look at what the next five years do to all of this.

If you skip to the FAQ at the bottom, I get it, it’s there for you.

What counts as a background image in email (and why it’s not a normal image)

Quick definitional bit, because the small-business folks and the producers reading this don’t always need the difference spelled out and the developers can skim.

A background image is an image that sits behind other content – text, a button, a logo, whatever – rather than being the content itself. That’s the whole distinction. A hero image where the headline is baked into the picture is just an image. A hero where the headline is live HTML text sitting on top of a photo is a background image. The second one is harder to build and the reason you’d bother is that live text stays selectable, stays translatable, scales for accessibility, and doesn’t turn into a blurry mess on a high-DPI screen.

There are basically two places you’ll apply one:

• The whole email body – a texture or color wash that surrounds the entire layout, behind everything.
• A single section or cell – a hero band, a feature block, a footer with a pattern. This is the common one, and it’s the one that breaks in interesting ways.

And here’s the thing people conflate constantly: a background image is not the same as a background color. The color is bulletproof – every client on earth respects bgcolor. The image is the fragile part. Which is exactly why the color does double duty as your fallback, and we’ll come back to that more than once because it’s the single most important habit in this whole topic.

The honest support picture – which clients render background images in HTML email in 2026

Most guides open with “background images are widely supported now!” and then spend the rest of the article explaining the eight ways they aren’t. So let me just give you the real map up front. Here’s where background images in HTML email actually render in 2026, and how.

The short read:

the modern stuff is genuinely fine, and if your whole list is on Apple Mail and a recent Outlook you can almost code these like it’s a normal web page. The problem is the two awkward edges. Classic Outlook needs Microsoft’s ancient VML language to show a background image at all, and Gmail occasionally decides to be difficult about how you declare the image. Most of the rest of this article is about handling those two edges without breaking everything in between.

One note worth saying out loud: Microsoft Outlook for Windows in its classic, Word-rendering form simply does not support the CSS background-image property. Not partially, not with a workaround flag – it ignores it. That’s been true since 2007 and it’s still true on the classic builds people are running right now. The VML approach isn’t a “nice to have” for those users, it’s the only thing that puts a pixel of your image on their screen.

The Gmail thing everyone’s still scared of (and why the scary version is over)

This is the part I lead with when I’m reviewing someone’s code, because most of the “how to add a background image to an email” posts that rank on Google are old enough to describe a bug that no longer exists, and people keep cargo-culting fixes for a problem Gmail already reverted.

Here’s what actually happened. Back in July 2023, Gmail’s webmail in Chrome started, for a subset of accounts, doing something genuinely nasty: if it detected background-image: url(...)orbackground: url(...) inside an inline style attribute, it didn’t just drop the background – it stripped out the entire style tag on that element. Padding, font, color, all of it, gone, because you’d put a background image in the wrong place. The email dev community lost its collective mind for about a week, and fair enough.

And then – this is the part the old tutorials never circle back to update – Google acknowledged it and rolled it back. The rollback was complete by early August 2023. If you check caniemail today, Gmail Desktop Webmail moved from that buggy July state straight back to “supported” in August 2023, and Google’s own CSS support docs still list both background and background-image as supported properties. So the doomsday scenario where Gmail eats your whole style block on sight of a background image? That’s not a thing in 2026. It was a three-week scare two and a half years ago.

I lost a chunk of an afternoon to it back in 2023 on a template that hadn’t changed, so I’m not pretending it wasn’t real. It was real, and then it wasn’t.

So why does everyone still tell you to use the background attribute?

Because it’s still the right call – just for reasons that have nothing to do with the rolled-back bug. Two of them, mainly:

GANGA. That’s email-dev shorthand for the Gmail App for Non-Google Accounts – when someone adds their Outlook or Yahoo address into the Gmail mobile app. CSS background-image straight-up isn’t supported on non-Google accounts there, and GANGA doesn’t read the HTML background attribute on a cell either. It wants CSS shorthand instead:

background: url('https://yourcdn.com/hero.jpg') center / cover no-repeat #1a2b4c;

The slash syntax (center / cover) is the shorthand for position and size. So if GANGA is meaningful in your audience numbers, you end up declaring the background more than one way and accepting a bit of redundancy. If GANGA is a rounding error for your list, skip it. Check your analytics; don’t carry code for clients nobody uses.

Gmail still nukes whole <style> blocks for other reasons. This part never went away and trips people up constantly. Gmail will drop an entire <style> block if it hits something it considers an error – nested @ declarations (common with web fonts), or a style block that runs past 8192 characters. So the instinct the 2023 panic drilled into everyone – keep your background CSS isolated, lean on the HTML background attribute, don’t cram a url() in alongside a pile of other critical inline CSS – is good hygiene regardless. The bug got reverted; the habit it taught is worth keeping.

The practical recipe

Use the HTML background attribute on the <td> as your primary method, with the sizing in CSS:

<td width="600" background="https://yourcdn.com/hero.jpg"
    bgcolor="#1a2b4c"
    style="background-size: cover; background-position: center center;">
  <!-- content -->
</td>

Standard Gmail reads the background attribute, honors background-size: cover and background-position from the inline style, and you’re covered. It feels slightly hacky to mix an HTML attribute and CSS properties to describe one background, and it is, but email isn’t a web page, it’s a hostage negotiation, and this is the deal that works across the most clients with the least drama.

How to code bulletproof background images in HTML email, step by step

Right, the actual build. This is the canonical recipe for background images in HTML email, and I’m going to construct one full-width hero background with live text and a button on top, the way I’d build it for a real campaign, and explain each layer as it goes on. The order I add things in is deliberate – the fallback comes first, always, because the fallback is the thing that saves you when everything else fails.

Step 1: the container and the fallback color

Start with the cell, set the fallback bgcolor, and span it to full width inside your usual content table.

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center" valign="top" bgcolor="#1a2b4c">
      <!-- everything else goes inside here -->
    </td>
  </tr>
</table>

That bgcolor="#1a2b4c" is doing more work than it looks like. When the recipient has images turned off, when a corporate firewall blocks your image host, when Apple’s Mail Privacy Protection prefetches things weirdly, when the image is simply slow – the fallback color is what’s behind your text. Pick it so your overlaid text is readable on the color alone, not just on the image. If your headline is white and your fallback is white, congratulations, you’ve shipped an invisible email. I have seen this go out. More than once. Not always mine.

Note the role="presentation" on the table too – that’s an accessibility requirement, not a style choice. Without it, screen readers try to read your layout table as a data table and produce nonsense. Every layout table needs it.

Step 2: the background for the modern clients

Now add the image so the webmail and modern clients can see it – the HTML background attribute plus the sizing CSS.

<td align="center" valign="top"
    background="https://yourcdn.com/hero.jpg"
    bgcolor="#1a2b4c"
    style="background-image: url('https://yourcdn.com/hero.jpg');
           background-position: center center;
           background-size: cover;
           background-repeat: no-repeat;">

Worth a quick word on why I’m declaring it both ways. Apple Mail, Outlook.com and a few others want the CSS declaration; standard Gmail reads the background attribute. The two can coexist, and each client grabs the one it understands. Since the 2023 style-stripping bug got rolled back, keeping the url() in the inline style is no longer the liability it briefly was – but keep your other important CSS off this cell anyway, because of the unrelated <style>-block stripping I mentioned and just because isolating background properties on the background cell keeps you out of trouble. For a hero where the style block only holds background properties, you’ve got nothing to lose either way.

This is the kind of thing that sounds like nitpicking until it eats your layout. Test it for your specific template – I’m not going to pretend there’s one universally clean answer, because there isn’t.

Step 3: VML for classic Outlook

Classic Outlook can’t see a single thing you just did. So we feed it Microsoft’s Vector Markup Language inside a conditional comment that only Word-based Outlook will read. Everyone else treats it as a regular HTML comment and ignores it.

<!--[if gte mso 9]>
<v:image xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false"
         style="width:600px; height:400px;"
         src="https://yourcdn.com/hero.jpg" />
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false"
        style="position:absolute; width:600px; height:400px;">
<v:fill opacity="0%" color="#1a2b4c" />
<v:textbox inset="0,0,0,0">
<![endif]-->

<div>
  <!-- your real overlaid HTML content lives here -->
</div>

<!--[if gte mso 9]>
</v:textbox>
</v:rect>
<![endif]-->

Three VML elements are doing the work:

• <v:image> draws the background image itself at fixed pixel dimensions.
• <v:rect> is a rectangle the same size that sits on top, and it’s the container your real content will be positioned inside.
• <v:fill opacity="0%"> makes that rectangle transparent so the image shows through, while still naming your fallback color.
• <v:textbox> is the box your actual HTML (the <div> with your heading and button) gets placed into, layered over the image.

A couple of things that bite people here:

VML uses points, not pixels, for some measurements. If you’re converting a pixel value, multiply by 0.75 – so 600px becomes 450pt. The width/height in the snippet above are fine as px, but the moment you start positioning with VML’s own units, remember the 0.75 conversion or your sizing goes sideways.

And the most common Outlook-specific gotcha after that: classic Outlook likes to drop a ~20px gap below images. The fix is wrapping things so a font-size: 0; div kills the whitespace. It’s stupid, it’s been true for over a decade, and you’ll forget it and then remember it when you see the gap.

Step 4: the overlaid content, done right

Inside that <div>, build your heading and button as normal HTML, but keep two Outlook rules in mind:

1. Don’t put padding on the div. Classic Outlook ignores padding on a <div>. Put your spacing on a nested <td> instead. This one catches people every single time because their local Chrome preview respects div padding just fine, so it looks correct right up until it reaches Outlook.
2. Constrain the text width so it doesn’t sprawl across the full image on desktop. A centered inner table at a sensible max width keeps the composition intact.

Step 5: the whole thing assembled

Here’s the full pattern stitched together, ready to adapt:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
  <tr>
    <td align="center" valign="top"
        background="https://yourcdn.com/hero.jpg"
        bgcolor="#1a2b4c"
        style="background-image: url('https://yourcdn.com/hero.jpg');
               background-position: center center;
               background-size: cover;
               background-repeat: no-repeat;">

      <!--[if gte mso 9]>
      <v:image xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false"
               style="width:600px; height:400px;" src="https://yourcdn.com/hero.jpg" />
      <v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false"
              style="position:absolute; width:600px; height:400px;">
      <v:fill opacity="0%" color="#1a2b4c" />
      <v:textbox inset="0,0,0,0">
      <![endif]-->

      <div>
        <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0">
          <tr>
            <td align="center" style="padding: 80px 24px;">
              <h1 style="margin:0; color:#ffffff; font-family:Arial,sans-serif; font-size:32px;">
                Your headline on the image
              </h1>
              <a href="https://example.com"
                 style="display:inline-block; margin-top:24px; padding:14px 28px;
                        background:#ff6b35; color:#ffffff; text-decoration:none;
                        font-family:Arial,sans-serif; font-size:16px; border-radius:4px;">
                Read more
              </a>
            </td>
          </tr>
        </table>
      </div>

      <!--[if gte mso 9]>
      </v:textbox>
      </v:rect>
      <![endif]-->

    </td>
  </tr>
</table>

That’s a working bulletproof background. Copy it, swap your image URL, your fallback hex, your copy, and test it before you trust it. Which brings me to the shortcut a lot of people reach for and the honest caveat that comes with it.

A word on generators

There are free code generators that spit out bulletproof background blocks for you – Campaign Monitor’s backgrounds.cm tool is the long-standing one, and a few ESPs have their own. They’re fine. They save you the boilerplate. But generated code is a starting point, not a finished product – it doesn’t know your fallback color needs, it doesn’t know your audience’s Gmail-vs-GANGA split, and it absolutely doesn’t excuse you from testing. Use them to skip the typing, not to skip the thinking.

Making background images responsive (the part that breaks on mobile)

So your background looks great at 600px wide on desktop. Then someone opens it on a phone and the image either over-crops, leaves a strip of fallback color along the bottom, or stretches your overlaid text into an unreadable smear. Making background images in HTML email responsive is where background-size: cover and a particular Gmail bug come for you.

The Gmail cover height bug

Here’s a fun one that’s been documented in the Litmus community for years and still isn’t fixed: in Gmail, background-size: cover covers the width of the cell but doesn’t reliably stretch the height. So on a tall mobile layout, you get the image filling the top portion and then a band of your fallback color filling whatever vertical space is left over. It looks like a bug in your code. It’s a bug in Gmail.

The workaround people land on is controlling the cell’s height by controlling the content height – and one approach I’ve used is a sort of reverse media query. You set a smaller font size as the baseline so the cell doesn’t grow taller than the image can cover, then use a min-width media query (which Gmail webmail on desktop ignores, because it doesn’t do media queries there) to bump the font back up for clients that do support media queries. It’s backwards from how you normally think about responsive type, and it feels wrong, and it works. Sometimes the email is shaped weird, you swallow it, you move on.

Build the base layout fluid first

The structural advice here overlaps heavily with fluid hybrid email design – and if you’re not already building on a fluid-hybrid foundation, that’s the bigger fix. Percentage widths and max-width constraints mean the background cell adapts to whatever container it lands in, and then media queries become a layer of polish on top rather than the thing holding your layout up. A background image on a rigid fixed-width table will fight you on mobile; a background image on a fluid cell mostly behaves.

The principle that’s saved me the most grief: design the section so it’s legible even if the image gets cropped to its worst-case visible area. Don’t put critical text in a corner of the image that mobile will crop off. Keep the important stuff center-ish, keep the contrast high, and assume some part of your beautiful photo is getting eaten on a narrow screen.

Background images and dark mode – the collision nobody plans for

This is the section the generic guides skip, and it’s where I think the real money is, because dark mode and background images in HTML email interact in a way that quietly wrecks emails and almost nobody designs for it on purpose.

Quick grounding: dark mode isn’t one behavior, it’s three, depending on the client.

• Apple Mail (macOS / iOS) gives you the most control. It honors the prefers-color-scheme media query, so you can supply explicit dark-mode overrides. It also inverts aggressively if you don’t.
• Outlook (desktop, classic) barely changes anything in the message body.
• Gmail (mobile, Android especially) does partial inversion – it darkens light backgrounds but leaves images and some elements alone, and it ignores prefers-color-scheme for your custom overrides.

Now picture your background hero in that world. The image is a photo, so dark mode leaves the image alone – photos don’t get inverted in most clients. But your fallback color might get inverted. So in a client doing partial inversion, if the image loads, you see the photo; if the image doesn’t load, you see an inverted version of your fallback color, and the white text you designed for a dark navy fallback is now sitting on a light inverted version of that navy, completely illegible.

That’s the collision. The image and the fallback get treated differently, and your overlaid text was only ever designed for one of them.

How I handle it

• Don’t use pure white or pure black for the fallback. Many dark-mode algorithms skip inversion on colors that aren’t pure #ffffff or #000000. Reaching for #fefefe instead of #ffffff, or #1a1a1a instead of #000000, sometimes dodges the inversion entirely. It’s superstition-adjacent, but it works often enough that I do it by default.
• Use prefers-color-scheme for Apple Mail to set a dark-appropriate fallback color and, where it matters, swap any overlaid logo for a transparent-PNG version that reads on both light and dark. Remember this only reaches Apple Mail and Outlook for Mac – it’s progressive enhancement, not a guarantee.
• Make overlaid logos and icons transparent PNGs. The single most common dark-mode complaint I hear is “our logo looks terrible,” and it’s almost always a PNG with a baked-in white background sitting on a dark hero, getting a white halo when the surrounding area darkens. Five minutes in an image editor, transparent background, fixed forever.
• Test in actual dark mode, on actual devices. A browser toggle is not the same as Gmail’s dark mode on a real Android phone. The rendering disagrees, and the disagreements aren’t documented anywhere you can look up.

If you do nothing else from this section: check what your overlaid text looks like against the inverted fallback color, not just against the loaded image. That single check catches most dark-mode background disasters.

Where background images in HTML email go wrong – a failure checklist

Most of these I’ve done myself at least once, usually late, usually the night before a launch. Run through them before you send.

No fallback color set. Image blocks, image fails, or images-off by default – and your text is floating on nothing or on white. The bgcolor is non-negotiable. It’s the floor under everything.

VML written in pixels where it needs points. Sizing goes wrong in classic Outlook and you can’t figure out why the local preview looks fine. Multiply px by 0.75 for VML’s point-based measurements.

The VML block sitting outside its conditional comment. If the <!--[if gte mso 9]> boundaries are off, the VML renders in every client, not just Outlook, and now everyone gets a broken fixed-size version of your background. Double-check where your comments open and close. This is a 30-second mistake that costs you a whole campaign.

Cramming critical CSS onto the same cell as a background-image: url(). The big 2023 Gmail bug that made this fatal got rolled back, but Gmail still drops an entire <style> block when it hits invalid CSS or blows past the 8192-character limit, so isolating your background CSS on the background cell and leaning on the HTML background attribute is still the safe habit. Don’t tempt it.

Overlaid text that fails contrast once the image loads. WCAG 2.2 AA wants a 4.5:1 contrast ratio for body text. A busy photo behind white text can drop below that in the lighter regions of the image. A subtle dark gradient overlay on the image, or a semi-transparent color layer, buys back the contrast without hiding the photo.

Image too large in file size or dimensions. Classic Outlook has been known to choke – and in older builds, outright crash – on background images deemed “too big.” Keep your hero around your content width (600 to 650px is the sweet spot) and keep the file weight sane. Test in a real Outlook before you trust a large background.

Forgetting that Apple’s Mail Privacy Protection prefetches your image. MPP pulls every remote image through Apple’s proxy at delivery time, whether or not the person opened the email. It doesn’t break your background – but it does mean your “image loaded” assumptions and your open-rate signals are both unreliable now. Don’t design as if a loaded image guarantees an engaged reader.

Trusting the browser preview. Your local Chrome render respects div padding, CSS backgrounds, and modern layout – all the things classic Outlook doesn’t. The browser will lie to you cheerfully. You cannot eyeball this; you have to render it where it’ll actually be opened.

Do background images in HTML email still matter once classic Outlook dies?

This is the part where I have to correct something that’s all over the internet right now, because a lot of “you can stop writing VML soon” takes are built on a date that’s been quietly moved.

The new Outlook is genuinely better – for backgrounds especially

The new Outlook for Windows uses a Chromium-based engine (Microsoft Edge WebView2), the same family of technology behind Outlook.com. For background images that’s great news: it supports CSS background-image properly, it handles background-size, and it ignores VML entirely – which means your old conditional-comment code just does nothing there and doesn’t hurt anything. Background and margin and padding on divs behave like a normal browser. After almost twenty years of the Word engine making everyone miserable, backgrounds finally “just work” in the new client.

There’s a catch, because there’s always a catch: the new Outlook runs a post-processing layer that rewrites some styles after the email loads. The famous example is border-radius – set different corner values and it can flatten them to a single radius on all four corners. So “Chromium-based” doesn’t mean “identical to Chrome.” Test the new Outlook specifically; don’t assume.

The timeline everyone’s quoting is out of date

Here’s the bit that actually changes your decision. The often-repeated line is that Microsoft ends support for the Word-rendering classic Outlook in October 2026, full stop. That’s not the whole story anymore.

What’s actually true as of mid-2026:

• The opt-out phase – where the new Outlook becomes the default but users can still switch back – was originally slated for April 2026. In late February 2026 Microsoft pushed it to March 2027 for enterprise environments, giving organizations 12 months of lead time.
• The cutover phase – where you can no longer switch back to classic – has no public date and won’t begin earlier than roughly March 2028, after that 12-month notice.
• Classic Outlook keeps getting support, including security updates, through at least 2029 for Microsoft 365 subscribers and anyone on perpetual licenses like Office 2021, Office 2024, and Office LTSC.

So the corporate machine in that basement office is going to be opening your emails in Word-engine Outlook for years yet. Enterprise IT does not move because Microsoft published a blog post. Banks, government, healthcare, insurance – anyone with a real change-management process – will be on classic Outlook well into 2028 and 2029, and your B2B audience is exactly the slow-moving part of the market.

My honest five-year read

I could be wrong about parts of this – anybody who tells you they know exactly how a Microsoft transition plays out is guessing with confidence. But here’s where I’d put my money:

• 2026 – 2027: VML and the full bulletproof stack are still mandatory for any B2B sender or any list with meaningful corporate Outlook share. The opt-out delay means nothing forces users off classic during this window.
• 2027 – 2028: Audience analysis starts mattering more than the calendar. A 90%-mobile consumer list? You can start trimming legacy code. An enterprise B2B list? You can’t, not yet.
• 2028 – 2030: Background-image VML shifts from “must have” to “legacy fallback I maintain for the long tail.” You keep it in working templates and stop adding it to brand-new consumer ones.
• Beyond 2030: Assuming Microsoft doesn’t change course again, it fades into background maintenance. Still works, nobody’s teaching it.

The technique outlives Outlook anyway

Here’s what the “is this dying” hot takes miss. Bulletproof background coding was never only about Outlook. The same defensive approach also covers:

• ESPs that rewrite or strip parts of your HTML during template processing
• Gmail’s ongoing habit of changing what CSS it’ll accept (see: the entire 2023 saga, which it then reversed – the point being you can’t count on this quarter’s behavior holding next quarter)
• Email forwarded into clients you genuinely cannot predict
• Old webmail apps that haven’t been updated since 2018 and never will be
• Embedded previews in collaboration tools that don’t render external stylesheets

A fallback color behind every background image is good engineering regardless of which client is the villain this year. So even after classic Outlook is finally in the ground, building background images in HTML email that don’t assume perfect CSS support is just… the correct way to do it. That habit doesn’t expire.

Tools for building and testing background images in HTML email

You cannot QA a background image by looking at it in your browser. I’ll keep saying it because people keep trying. Here’s what I actually use and what it costs now, because the testing-tool market got genuinely worse for small teams in the last year and pretending otherwise would be dishonest.

Litmus

Still the most thorough previewing tool for serious email QA, and I’m recommending it with a giant asterisk taped to it. Litmus shows you screenshots across roughly 100 client and device combinations – every Outlook version you care about, Apple Mail, the Gmail variants, dark-mode previews, all of it. For catching version-specific background quirks, the DPI hairlines, the Outlook rendering oddities, it’s the best there is.

The asterisk is the price. Litmus was acquired by Validity in April 2025, and on August 1, 2025 they killed the old Basic plan with effectively no notice and moved the entry point up to the Core plan at $500 per month – that’s 2,000 previews, 5 seats, and a pile of analytics and personalization features bundled in whether you want them or not. Pay monthly and that’s $6,000 a year; the annual plan knocks roughly 17% off, landing just under $5,000. The old $99/month Basic tier and the $199 Plus plan are both gone, with no monthly small-team option to replace them.

For an in-house team running dozens of campaigns a month, the value’s still there. For a freelancer testing two emails a week, or a small agency with a few retainer clients, $500/month to look at screenshots is hard to justify. I still pay it because my client mix earns it back, but I’ve stopped recommending it as the automatic default.

Heads up if you’ve used Putsmail: Litmus’s free send-yourself-a-test tool, Putsmail, has been retired – the site now just says so. It was a handy free way to fire a quick test to your own inboxes for years, and it’s gone, so don’t build a workflow around it.

Mailgun Inspect (formerly Email on Acid)

Email on Acid has been folding into Mailgun Inspect, and for small-to-mid teams this is the sensible default now that Litmus priced out the bottom of the market. The formal transition for existing subscribers starts in June 2026, with annual customers migrating at the end of their current term – and worth knowing, your existing previews and saved tests don’t carry over, so don’t treat the migration as a no-op. Comparable rendering coverage, historically around half the price, plus newer accessibility checks aligned with WCAG 2.2 and the European Accessibility Act. Spam testing got reworked too: you can no longer fire a spam test from your own IPs, everything routes through Mailgun’s, and full in-app HTML editing is slated to arrive later in 2026. If you’re shopping fresh and you don’t need Litmus’s analytics suite, start here.

The real-hardware test

Virtual previews run on virtual machines, and virtual machines aren’t real devices – close, but not the same. If you can keep one actual Outlook desktop install on an old laptop, do it. Mine is a 2019 ThinkPad running Outlook 2019 on Windows 10, and it catches background-image gaps and DPI weirdness the virtual previews miss. A physical phone with the Gmail app installed earns its keep the same way – the real Gmail render occasionally disagrees with the simulator on background behavior in ways nobody’s documented.

Cheaper and free options worth knowing

• Mailtrap – a sandboxed test inbox, cheaper than the big two, good for development-stage checks though lighter on full client previews.
• HTMLemail.io – simple, free, fine for a quick sanity check.
• The real-inbox test – send to your own Gmail, Outlook, Apple Mail and Yahoo accounts before production. Yes, even for small sends. Especially for small sends, because that’s when people get lazy and that’s when the background falls apart in front of the whole list.

My own background-image QA loop: build it, preview in Litmus, fix what Litmus flags, send to myself across the four major inbox types, fix what looks wrong on the real phone and the real ThinkPad, then send. It adds maybe half an hour. It has saved me from more than one “the launch email is broken” phone call that I can specifically remember, and the half hour is cheaper than the phone call every time.

FAQ: background images in HTML email

Do background images work in Gmail?

Yes. Gmail webmail renders background images, and caniemail and Google’s own CSS docs both currently list background and background-image as supported. The safest way to declare one is still the HTML background attribute on a table cell with your sizing in CSS, partly out of habit from a 2023 bug (since reversed) and partly because it sidesteps the Gmail App for Non-Google Accounts (GANGA), which doesn’t support CSS background-image and wants shorthand instead. Use the background attribute as your primary method and add the shorthand if GANGA matters to your list.

Why doesn’t my background image show in Outlook?

Because classic Outlook for Windows uses Microsoft Word’s rendering engine, which ignores the CSS background-image property completely. To show a background image in classic Outlook you have to use VML (Vector Markup Language) inside an <!--[if gte mso 9]> conditional comment. The new Outlook for Windows, which is Chromium-based, handles CSS backgrounds normally and doesn’t need the VML at all.

What is a bulletproof background image?

A bulletproof background image is one coded to display correctly – or fail gracefully – across every email client regardless of its CSS support. In practice that means three layers working together: the HTML background attribute and CSS for modern webmail clients, a VML block for classic Outlook, and a solid fallback bgcolor that shows readable content when the image is blocked, stripped, or slow to load.

Do I still need VML for background images in HTML email in 2026?

Yes, if any meaningful part of your audience uses classic Outlook for Windows – which most B2B and corporate lists do. Despite the new Outlook rollout, the enterprise opt-out phase was delayed to March 2027, the cutover has no public date and won’t start before roughly March 2028, and Microsoft supports classic Outlook through at least 2029 for subscription and perpetual-license users. Audit your own analytics; once classic Outlook drops below about 5% of your opens, you can start removing VML from new templates.

How do I add a fallback color for a background image?

Set the bgcolor attribute on the same table cell that holds your background image, and pick a color your overlaid text stays readable against on its own. For VML, name the fallback in the <v:fill> color attribute. The fallback is what your recipients see whenever the image fails to load, so it’s the most important part of the whole setup, not an afterthought.

Can I make a background image responsive in email?

You can, but plan for two things. Build the section on a fluid-hybrid foundation using percentage widths and max-width so the cell adapts to any screen, and design so your overlaid text stays legible even when the image crops on narrow screens. Watch for the Gmail bug where background-size: cover covers the width but not the full height on tall mobile layouts, leaving a strip of fallback color – controlling the content height is the usual workaround.

Do background images work in dark mode?

The image itself usually survives dark mode untouched, since most clients don’t invert photos. The risk is your fallback color and overlaid text. Some clients invert the fallback color while leaving the image alone, so text designed for the original fallback can become unreadable when the image doesn’t load. Use non-pure fallback colors (like #1a1a1a instead of pure black), supply prefers-color-scheme overrides for Apple Mail, use transparent PNGs for overlaid logos, and test on real devices in real dark mode.

What size should an email background image be?

Keep the image around your content width – 600 to 650px is the standard target – and keep the file weight reasonable. Oversized background images have been known to make classic Outlook choke or even crash, and large files just slow the whole email down. Optimize the image, and if you need it to fully cover a taller area, size it generously enough to cover without forcing a huge file.

Can a non-developer add a background image to an email?

Swapping the image, color, or copy inside an existing bulletproof template – yes, a careful marketer or producer can manage that. Building one from scratch, or restructuring the columns and layout around it, really needs someone comfortable hand-coding HTML and the Outlook VML quirks. Drag-and-drop ESP builders offer background-image fields, but many of them don’t render reliably in classic Outlook because they skip the VML, so check what the builder actually outputs before you trust it on a real campaign.

Did Gmail really used to strip background image styles?

Yes, briefly. In July 2023 Gmail webmail in Chrome started removing the entire inline style attribute (or <style> block) on any element where it found background-image: url() – not just the background, everything in that block. It hit a subset of accounts, caused a week of panic in the email dev community, and then Google acknowledged it and rolled it back, complete by early August 2023. It is not current behavior in 2026. The lesson that stuck around: keep your background CSS isolated on the background cell, because Gmail still drops whole <style> blocks for other reasons like invalid CSS or exceeding its 8192-character limit.

The short version

Background images in HTML email are one of those things that look simple in a design mockup and turn into a small engineering project the moment you open a real Outlook. The core of it never really changes: declare the image so the modern clients and Gmail both accept it, feed classic Outlook its VML, and put a solid fallback color behind everything so the email survives when the image doesn’t. Do that and your hero holds up in Apple Mail, in Gmail, in the new Outlook, and in the Word-engine relic somebody’s still running in 2029.

The two things that’ll actually set your emails apart from the templated junk in everyone’s inbox are the ones the generic guides skip – knowing which Gmail “rules” are current and which are leftover panic from a bug that got reverted, and checking what your background does in dark mode when the fallback inverts and the image doesn’t. Get those right and you’re ahead of most people shipping email right now.

And if you want a quick read on whether the developer building your emails knows what they’re doing, ask them two things: what bgcolor is for on a background cell, and whether they test in real Outlook or just trust the Litmus screenshots. The answers tell you most of what you need to know.

I’ve got follow-ups coming – one going deeper on dark-mode patterns, since this article only scratched it, and one on where container queries take email layout over the next couple of years. They’ll be on the blog when they’re done. Subscribe if you want them to land in your inbox, ideally with the background image rendering correctly.