Retina Background Images in Email

A background image that looks crisp on a desktop monitor renders visibly soft on a phone, because the phone packs two or three device pixels into every CSS pixel. This guide covers serving a higher-density asset for those screens, keeping the file weight manageable, and getting the Outlook path right.

Root Cause: One CSS Pixel Is Several Device Pixels

A CSS pixel is a unit of layout, not of hardware. On a typical phone the device renders two or three physical pixels for each CSS pixel, so an image declared at 600 CSS pixels wide is being drawn across 1200 or 1800 physical ones. The client upscales, and upscaling a bitmap produces the soft, slightly blurred result that reads as low quality.

Email has no srcset — it is honoured by almost no client — so the resolution-switching mechanism the web uses is unavailable. What works instead is serving a single asset at twice the display size and declaring the display size explicitly, letting every client downscale rather than upscale.

Downscaling is the key asymmetry. A 1200px image displayed at 600px looks correct on both a standard screen and a high-density one, because downscaling loses information gracefully while upscaling invents it badly. The cost is file weight, which is what the rest of this comes down to managing.

Because email cannot switch assets by density, one double-density file downscaled everywhere is the only approach that works across both screen types.

The Exact Implementation

The display size must be declared explicitly, or the client renders the asset at its intrinsic size and the section is twice as tall as intended.

<td background="https://cdn.example.com/hero@2x.jpg"
    bgcolor="#450920"
    style="background-image:url('https://cdn.example.com/hero@2x.jpg');
           /* The declared SIZE is what forces the downscale. Without it the
              browser paints the asset at 1200px and the section doubles. */
           background-size:600px 300px;
           background-position:center center;
           background-repeat:no-repeat;
           /* The solid colour is the layer that always paints: images are
              blocked by default in Outlook and often elsewhere. */
           background-color:#450920;
           height:300px;">

  <!--[if gte mso 9]>
  <v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false"
          style="width:600px;height:300px;">
    <!-- VML has no background-size, so the asset must be sized by the shape.
         type="frame" scales the image to the rect rather than tiling it,
         which is what makes the 2x asset render at the right size. -->
    <v:fill type="frame" src="https://cdn.example.com/hero@2x.jpg" color="#450920"/>
    <v:textbox inset="0,0,0,0">
  <![endif]-->

  <div>
    <!-- Real content, authored once, rendered by every client. -->
  </div>

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

The declaration that does the work is background-size. Without it a 1200px asset paints at 1200px, the container grows, and the layout breaks in a way that looks unrelated to image density. With it, every client paints the asset at 600 CSS pixels and the high-density screens use the extra detail automatically.

For the VML path, type="frame" is the equivalent: it scales the fill to the shape's declared dimensions. The default tiling behaviour would repeat a 1200px asset inside a 600px rect, producing a visibly cropped and repeated background.

Managing the Weight

A double-density asset has four times the pixel count, and naive export produces roughly four times the file size — which on a message already approaching the clipping threshold matters. Three techniques recover most of that.

Compress more aggressively than you would at 1x. Compression artefacts that are visible at 1:1 are invisible once the image is downscaled by half, because the downscale averages them away. A quality setting that looks unacceptable in isolation frequently looks perfect at display size — 60 to 70 is often indistinguishable from 90 after downscaling.

Choose the format by content. Photographic backgrounds compress far better as JPEG; flat colour and gradients as PNG-8 with a reduced palette. A gradient exported as JPEG picks up banding that the downscale does not hide.

Blur what does not need detail. A background is behind text, so it should be low-contrast and unfussy anyway. A slight blur applied before export both improves legibility of the overlaid copy and compresses dramatically better, because there is less high-frequency detail to encode.

The compression headroom exists precisely because the asset is never displayed at its native size.

Variant: When Not to Use a 2x Background

Three cases where the extra weight is not justified.

A background that is a flat colour or a simple gradient should not be an image at all. background-color covers the flat case at zero bytes, and a two-stop gradient can be a very small PNG tiled horizontally — a 1px-wide strip repeated across the width, which is both sharper than any bitmap and a fraction of the weight.

A background hidden behind a solid content card is barely visible, so its density is irrelevant. Where only a narrow border of the image shows around a white content panel, a 1x asset is indistinguishable.

A message already near the size budget should drop the 2x asset before it drops anything else. Sharpness on a background is the least valuable quality in the message, and losing the footer to clipping is a much worse outcome than a slightly soft hero.

Pipeline Integration

Generate the 2x asset as a build step from a single high-resolution source, rather than exporting it by hand alongside the 1x. Hand-maintained pairs drift — one gets updated and the other does not — and the failure is subtle, since a stale background looks fine until someone compares the two.

Assert the display dimensions in the same build check that measures message size. A background declared without an explicit background-size is a specific and detectable defect, and it produces a layout break rather than a subtle softness — which makes it worth failing the build over.

Designing the Artwork for the Fallback

Because a background image is blocked by default in Outlook and frequently elsewhere, the artwork has to be designed around a state in which it does not appear at all. Two design rules follow, and both are decided before the asset is exported.

The overlaid text must be legible on the fallback colour alone. That means choosing the solid bgcolor first and picking text colours against it, rather than choosing text against the image and hoping the fallback is close enough. A white headline over a photograph with a mid-grey fallback is unreadable in every client that blocks the image — which is most Outlook installations out of the box.

The image must be low-contrast where text sits over it. A background carrying strong tonal variation behind a headline produces a passage where the text is legible and another where it is not, and no single text colour fixes both. Darkening or blurring the region under the text — or overlaying a semi-opaque scrim baked into the asset itself — makes one text colour work everywhere. Baking it into the asset matters: a CSS overlay is another layer that can fail to render.

The practical test is to view the design with the image hidden and ask whether it still reads as intended. If the answer is no, the design depends on an asset that a large share of recipients will never see, which is a design problem rather than a coding one. This is the same test that applies to image-heavy messages generally, and a background is simply the case where it is easiest to forget.

The left column is a design that only exists when the image loads; the right one works in both states without any additional code.

Validation and Deployment Checklist

Frequently Asked Questions

Does `srcset` work in email?

Effectively no. A handful of WebKit-based clients honour it, and every other client ignores it and loads the src — so the practical outcome is that you serve one asset to almost everyone anyway. Serving the 2x asset as the single src with an explicit display size reaches every client and needs no fallback logic.

Should the image be 2x or 3x?

Two is the right answer. Three-times density exists on some phones, but the visible difference between 2x and 3x on a background image is negligible while the file weight grows another 125%. Backgrounds are low-contrast by design, which is exactly where extra density is least perceptible.

What about `image-set()`?

Support in email clients is close to nonexistent, and where it is unsupported the entire declaration is dropped — taking the background with it unless a plain background-image is also declared. That fallback requirement removes any benefit, since you end up serving the single asset regardless.

Does this apply to inline images too?

The same principle applies with a different mechanism: export at 2x and constrain with the width attribute plus a CSS max-width, so the client downscales. The attribute is what the Word engine reads and the CSS is what everything else reads, which is the same pairing described for fluid images.

Email Background Images and VML — the dual-path structure this sits inside
Full-Width Background Images in Outlook With VML — sizing the rect itself
Catching HTML Size Regressions in CI — the budget a 2x asset competes against
Responsive Email Layouts — the attribute-plus-CSS pairing used for inline images

← Back to Email Background Images and VML