Skip to content
EveryImage

2026-07-09 · 4 min read

Images in email: sizes, weight, and the clients that will break your layout

Why 600 pixels is still the working width, how to handle high-density screens, dark mode pitfalls, and why email is the one place where WebP is a bad idea.

Email rendering is the last major web-adjacent platform where the constraints of 2005 still apply. The clients are numerous, inconsistent, and in several important cases actively hostile to modern techniques. Images are where this bites hardest.

600 pixels, still

The conventional email body width is 600 pixels, and it persists because it works: it fits the reading pane of desktop clients without horizontal scrolling, and it scales down cleanly on phones.

Some templates now go to 640 or 680. Beyond that you are gambling on reading pane widths you cannot measure.

So the display width of a full-width email image is 600 pixels. That is the number your layout uses.

But export at 1200

Displaying a 600-pixel image at 600 CSS pixels on a modern phone means each image pixel covers four device pixels. It looks soft, in the specific way that makes an email feel cheap.

Export at 2× — 1200 pixels wide — and set the display width to 600 in the HTML and inline CSS:

<img src="header.jpg" width="600" style="width:600px; max-width:100%; display:block;" alt="Spring collection">

The width attribute is not optional here. Outlook's rendering engine needs it, and images without explicit dimensions are where email layouts most often collapse.

File weight matters more than on the web

Gmail clips messages above roughly 102 KB of HTML — that is markup, not images, but it is a reminder that email has hard limits the web does not.

For images, the constraint is different: many recipients are on mobile data, many are on slow connections, and an email that takes eight seconds to render is an email that was already deleted. A total payload under 1 MB is a reasonable ceiling, and under 500 KB is better.

That is achievable with a 1200-pixel header at quality 80 and a handful of smaller product images, provided nothing is accidentally full-resolution.

Use JPEG and PNG. Not WebP

This is the one context where the modern-format advice inverts.

Email clients are not browsers. Support for WebP is inconsistent across the client landscape, and the failure mode is not a fallback — it is a broken image icon in someone's inbox, which is considerably worse than a slightly larger file.

Use JPEG for photographs and PNG for graphics with transparency or hard edges. GIF for the rare case where you genuinely want a short animation, accepting that it will be large.

Images are often blocked entirely

Many clients block remote images by default until the recipient chooses to load them. Some privacy-focused clients proxy or strip them permanently.

The implication is structural: an email must be comprehensible with no images loaded at all. That means real text for anything important — headlines, prices, calls to action — and never an email that is one large image with the message baked into it.

It also makes alt text unusually important, because in a blocked-images email, the alt text is what the recipient reads. Write it as content, not as a description.

<img src="sale.jpg" alt="30% off all outdoor furniture until Sunday" width="600" style="width:600px;">

Dark mode will invert things

A growing share of clients apply dark mode transformations, and their behaviour varies from a considered colour mapping to a blunt inversion of everything.

The most common casualty is a logo saved as a black PNG on transparency — invisible against a dark background — or a product photograph on a white background sitting as a glaring white rectangle in an otherwise dark email.

Two defences: give logos a small amount of padding in a background colour that works in both modes, or supply a version with a light outline. For photographs, a subtle border keeps a white background from appearing as an unbounded bright block.

Testing across clients is the only way to be sure, and it is the part of email production that everyone under-budgets.

A batch recipe

For a typical campaign:

  • Header/hero: 1200 pixels wide, JPEG at quality 80, displayed at 600.
  • Product thumbnails in a two-column grid: 560 pixels wide, displayed at 280.
  • Logo: PNG, 2× its display size, with padding in a mode-safe colour.
  • Everything: consistent dimensions per row, so the grid does not shift.

Processing these as one batch with a fixed width and quality — rather than exporting each by hand — is what keeps a campaign visually consistent, and it is the difference between a template that renders predictably and one where every send is a surprise.

Hosting

Images in email are remote resources, so they need a stable public URL that will still resolve when someone opens the message in six months. Your ESP's own image hosting is usually the right answer, because it handles that lifetime for you.

Whatever you use, upload files that are already correctly sized. Most ESPs will happily host a 4000-pixel photograph and reference it at 600 pixels, and every recipient will download the difference.