Srcset

Quick answer: Srcset is an HTML <img> attribute that holds a comma-separated list of image files, letting the client pick one based on screen width or pixel density. On the open web it works great. In email it is supported in roughly a quarter of clients – Apple Mail says yes, Gmail, Outlook and Yahoo say no – so srcset is used mainly inside the <picture> element for fallbacks, not for responsive resizing.

The srcset attribute is one of those things that looks like the obvious answer and then quietly isn’t. You read the name. Source set. A set of sources. And you think, finally, a clean way to serve sharp images to retina screens and small files to phones, all in plain HTML, no CSS gymnastics. Then you ship it to email and most of your list never sees the clever part.

This entry covers what srcset is, why it mostly fails in email, the boring trick that actually works instead, and the one place where the srcset attribute genuinely earns its keep. Fair warning up front: if you came here to make email images responsive with srcset, you are about to get the honest version, not the tutorial version.

What srcset is

A normal image in HTML uses one attribute for its file. That is src. The client loads it, done. The srcset attribute sits right next to src and offers alternatives.

<img
  src="hero-600.jpg"
  srcset="hero-600.jpg 600w, hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 600px"
  alt="Product hero">

There are two ways to describe the options inside srcset. You can use a width descriptor, like 600w, which tells the client how wide each file actually is. Or a pixel density descriptor, like 2x, which means “use this one on retina screens.” The sizes attribute is the partner to width descriptors – it tells the client how wide the image will display at each breakpoint. The client does the math and picks a file.

On a website this is a solid tool. The browser saves bandwidth. A phone grabs the small file, a 4K monitor grabs the big one, and nobody downloads a 2000px image to view it at 300px. That is the whole pitch, and on the web it holds up fine.

How srcset is supposed to work

Two flavours of srcset exist, and they solve different problems. Worth knowing both before we watch them break.

The density descriptor (2x, 3x)

This is the retina version. You hand the client two files of the same image at different resolutions.

<img src="logo.png" srcset="logo.png 1x, [email protected] 2x" alt="Logo">

A standard screen takes the 1x file. A retina screen takes the 2x file and renders it sharp. Simple idea. No media queries, no CSS.

The width descriptor (600w) plus sizes

This is the responsive version. You list several widths and tell the client your layout intentions through sizes. The client picks the smallest file that still looks good. This is the proper “responsive images” use case the srcset attribute was actually built for. On the web it is genuinely useful. Hold onto that, because what happens next is not the attribute’s fault.

Why srcset mostly fails in email

Here is where the email world does what the email world does. The srcset attribute, on paper a clean solution, lands in inboxes and just doesn’t fire for most people.

Estimated support for the srcset and sizes attributes across email clients sits at around 24%, based on caniemail data last tested in 2019. Apple Mail supports it. Gmail, Outlook and Yahoo do not.

That number is the headline and it is brutal. Roughly twenty-four percent. Most of your subscribers are on Gmail or some flavour of Outlook, and in those clients the srcset attribute is ignored outright. The client falls back to whatever sits in plain src. So your careful list of widths and density options does precisely nothing for the bulk of your audience.

The clients that almost support it

There is a worse-than-nothing category too. A few clients – ProtonMail, Fastmail and Mail.ru among them – support the sizes attribute but not srcset itself. Read that again. They read your layout hints and then have no list to pick from. It is a combination that helps no one. You get the appearance of support with none of the behaviour, which is somehow more annoying than a flat no.

The Outlook problem, again

You cannot talk about anything failing in email without Outlook walking into the room. Classic Outlook for Windows renders mail with the Microsoft Word engine – the 2007-era one, yes, Word the document program. Word was never going to do browser-grade image negotiation. It does not weigh density descriptors and not parse sizes. It grabs src and moves on.

The newer Outlook for Windows runs a Chromium-based engine, much like Outlook on the web, and that version handles far more modern HTML. But you cannot target only the slice of your list that upgraded. Until classic Outlook actually retires – and Microsoft just pushed that runway out again, more on the timeline below – you build for the engine that ignores srcset.

Srcset support across email clients

So the takeaway is blunt. Do not reach for the srcset attribute to do responsive image resizing in email. The width descriptors and sizes will sit there looking productive while most inboxes ignore them entirely.

What actually works instead

This is the part that makes the page useful rather than just discouraging. If srcset cannot do retina images in email, something has to. Something does. It is not pretty, but it ships everywhere.

The technique is older than srcset and far more reliable in inboxes. You export your image at double size, then constrain it with the HTML width attribute and a CSS max-width.

<img
  src="[email protected]"
  width="600"
  style="width:100%; max-width:600px; display:block; border:0;"
  alt="Hero">

Three things are doing work here. The width="600" attribute is for Outlook, which obeys HTML width attributes and ignores CSS widths. The style="width:100%" makes the image fluid in everything else. And max-width:600px stops the doubled-up file from rendering at its full giant size and blowing out your layout.

Why this beats srcset in email

The image file itself is the high-resolution one. A 600px slot gets a 1200px file squeezed into it, so it stays crisp on retina screens. Standard screens downscale it and look fine. No density descriptor needed, no srcset needed. It works in Gmail, in Outlook, in Apple Mail, in the weird regional webmail clients you forgot existed.

Some versions of Outlook display retina images at full size regardless of width and height attributes. The max-width rule in the style is what reins them back in. Leave it out and you will get a 1200px image cheerfully shoving your whole table sideways.

The trade-off is honest. You ship a slightly heavier file to everyone, including phones that did not strictly need the extra pixels. For most emails that cost is small and worth it – sharp images beat a few saved kilobytes. This is the boring answer, and it is the right one for the vast majority of campaigns.

Where srcset is genuinely useful in email

Now the redemption arc. The srcset attribute is not useless in email. It just isn’t a resizing tool here. It is an engine, and the thing it powers is <picture>.

The <picture> element wraps one or more <source> tags plus a fallback <img>. Each <source> uses srcset to offer an option. The client checks the sources top to bottom and uses the first one it understands. If it understands none of them, it shows the <img>. That fallback is the whole point.

Use case one: modern format with a safe fallback

WebP files are smaller than JPEGs at the same quality. But classic Outlook breaks on WebP entirely – the image just doesn’t show – and Gmail quietly converts it to JPEG. So you offer WebP through srcset and keep a JPEG or PNG in the fallback.

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" width="600"
       style="width:100%; max-width:600px; display:block;"
       alt="Hero">
</picture>

<picture>
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" width="600"
       style="width:100%; max-width:600px; display:block;"
       alt="Hero">
</picture>

Clients that read WebP get the small file. Everyone else gets the JPEG. The same pattern works for SVG icons with a PNG fallback, which matters because Outlook for Windows renders no SVG at all.

Use case two: dark mode image swaps

You can swap an image based on the user’s colour scheme. A logo with dark text needs a light version for dark backgrounds. The srcset inside a <source> with a media query handles it.

<picture>
  <source srcset="logo-dark.png"
          media="(prefers-color-scheme: dark)">
  <img src="logo-light.png" width="200"
       style="display:block;" alt="Logo">
</picture>

Apple Mail respects this. It is one of the cleaner ways to handle dark mode logos without inverting colours and praying.

Use case three: reduced motion swaps

Some people set their device to reduce motion. You can serve them a static frame instead of an animated GIF or WebP, again using srcset inside <source> with a prefers-reduced-motion query. Animation for the people who want it, a still image for the people who don’t. Support is narrow, but since this one degrades to “everybody just sees the static image,” there is no real downside to adding it.

The gotcha that bites everyone: the u-tag rewrite

Here is the trap, and it is a real one. Some clients, including Outlook.com and the new Outlook, rewrite <picture> and <source> tags into <u></u> tags. Your structured markup gets gutted. When that happens, the only thing that survives is the fallback <img>.

So the rule is non-negotiable. Your fallback <img> must be a complete, correct, good-looking image on its own. Never stuff your only decent image into a <source> and leave junk in the <img>. Build it the other way round: put your safest, most universal image in <img> and treat every <source> srcset as a bonus for the clients that can handle it. Progressive enhancement, not progressive dependence.

I have been bitten by exactly this. Shipped a <picture> with a slick WebP in the source and a placeholder I had not finished in the <img>, previewed in Apple Mail where it looked perfect, and then watched the Outlook.com render serve the placeholder to a chunk of the list. Lesson learned, the hard way, on a live send.

Srcset vs picture vs the max-width trick

People conflate these three constantly. They are not interchangeable. Each has a job, and picking the wrong tool is most of the pain.

The short version. For making images crisp, skip srcset and use the doubled-image trick. For swapping formats or adapting to dark mode, the srcset attribute inside <picture> is exactly what you want. The width-descriptor flavour of srcset, the one that is supposed to be the headline feature, is the one you will use least in email.

Srcset and the next five years

Things are moving, slowly, in a direction that is mildly kinder to srcset. Worth mapping out, because building for today without an eye on the timeline is how you end up redoing everything in 2028.

The big lever is the new Outlook for Windows. It dropped the Word engine and runs a Chromium-style rendering core. That means real HTML and CSS, and a much better shot at honouring srcset and <picture> properly. As that version spreads, the share of inboxes that ignore the srcset attribute shrinks.

A rough timeline

• 2026 to 2027. Classic Outlook still holds a big chunk of business inboxes. Srcset for resizing stays a non-starter. The <picture> fallback pattern is already worth using today.
• 2027 to 2028. New Outlook becomes the default for more organisations. Support for <source srcset> widens. You still ship a fallback <img> every single time.
• 2028 to 2029 and beyond. If classic Outlook genuinely winds down, srcset-driven format swaps and art direction become realistic for a larger slice of lists. Microsoft already pushed its enterprise opt-out from April 2026 to March 2027, the cutover is no earlier than March 2028, and classic Outlook support runs to at least 2029. So this is a slow fade, not a cliff.

Across all of it, one thing does not change. The fallback <img src> keeps mattering. Image blocking, crawlers, old clients and the u-tag rewrite all depend on it. Build for the floor first, then layer srcset on top for the clients that can take it.

What about frameworks

Tools like MJML and Foundation for Emails generate clean markup for you. They do not magically fix srcset support, though. They cannot make Gmail honour a width descriptor it has never honoured. What they do is save you from hand-writing the tables and fallbacks. Understanding what the srcset attribute does by hand is still what lets you debug the output when a client does something weird. The machine writes it. You still have to know why it broke.

Common srcset mistakes in email

A handful of mistakes show up again and again. Each one is avoidable once you have been burned by it.

• Using srcset to resize and assuming it worked. It looked perfect in Apple Mail, so you shipped. Then Gmail showed the wrong file to most of the list. Apple Mail is not a representative test.
• Putting the good image in <source>. When the u-tag rewrite strikes, your fallback <img> is all that survives. If that holds a low-res placeholder, that is what most people see.
• Forgetting the src fallback entirely. No src means broken images for crawlers, image-blocking clients and anything that does not parse srcset. The src attribute is not optional, ever.
• Skipping testing because “it is just an image attribute.” The srcset attribute touches format support, dark mode and motion. That is plenty of surface area for one client to misbehave.
• Trusting a single preview. One inbox is not forty inboxes. The client you skipped is the one that breaks.

A note on testing

You cannot eyeball srcset behaviour across every client by hand. You need to see real renders. Testing platforms preview your email across dozens of clients and flag problems before send.

Two things worth knowing, because the landscape shifted. Litmus changed its pricing after the Validity acquisition, and the cheap entry tiers vanished – the old Basic plan is gone and the Core plan now starts at $500 per month for 5 users and 2,000 previews. Email on Acid, now under Sinch, is the more affordable competitor. And Putsmail, the old free send-a-test tool, has been retired – if a tutorial still points you there, the tutorial is stale.

Frequently asked questions

What is srcset in HTML email?

Srcset is an HTML <img> attribute that holds a list of image files. The client is meant to pick one based on screen width or pixel density. In email, srcset is only reliably supported in Apple Mail. It is used mainly inside the <picture> element to offer format and dark-mode fallbacks.

Does srcset work in Gmail and Outlook?

No. Gmail and classic Outlook for Windows both ignore the srcset attribute. They fall back to whatever is in the plain src attribute. The new Outlook for Windows, which uses a Chromium engine, handles more modern HTML, but you cannot target only upgraded users yet.

How do I make retina images sharp in email if srcset does not work?

Export the image at double size. Set the HTML width attribute, then add style="width:100%; max-width:600px". Outlook obeys the width attribute and other clients obey the CSS. This keeps images sharp on retina screens without using srcset at all.

What is the difference between srcset and the picture element?

Srcset is an attribute that lists image options. The <picture> element is a wrapper that holds multiple <source> tags plus a fallback <img>. Each <source> uses srcset to offer an option. In email, the srcset attribute is most useful inside <picture>, not on a bare <img>.

Is srcset worth using in email at all in 2026?

For resizing images, no. The width descriptors are ignored by most clients. For format swaps, dark mode and reduced-motion swaps inside <picture>, yes. Those are the cases where srcset genuinely helps, as long as you keep a solid fallback <img>.

Why does my srcset image show the wrong version in Outlook?

Some clients, including Outlook.com and the new Outlook, rewrite <picture> and <source> into <u> tags. That strips your srcset options and leaves only the fallback <img>. If that fallback holds the wrong image, that is what shows. Always put your safest image in <img>.

Key takeaways

• Srcset is an attribute listing image sources the client picks from. It was built for the open web.
• In email the srcset attribute is supported in roughly 24% of clients. Gmail, Outlook and Yahoo ignore it.
• For sharp retina images, use a 2x file with width plus max-width, not srcset.
• Srcset earns its place inside <picture> for format, dark mode and motion fallbacks.
• Always ship a complete fallback <img src>. Some clients rewrite <picture> into <u> tags.
• Support widens as the new Outlook spreads, but the fallback never stops mattering.

Srcset is a great web attribute wearing the wrong costume for email. Know what it does, use the <picture> version on purpose, and stop trying to make the width descriptors do a job most inboxes will not let them do. The doubled-image trick covers the common case. The srcset attribute covers the clever edges. Keep a fallback, test on real clients, and do not let Apple Mail tell you the whole story.