Image Handling in Email Clients

Many clients block images by default until the user clicks "show images". Outlook, Gmail (for unknown senders) and most mobile clients on a metered connection display a placeholder instead. Design assuming images may not appear.

Never bake critical copy (headings, CTA labels, prices) into images. Use HTML text styled with inline CSS so the message lands even when images are blocked, screen readers can read it, and dark-mode inverts adjust it appropriately.

Every <img> needs a descriptive alt attribute. When images are blocked, alt text appears in the placeholder box — well-written alt fills the visual void with the message that would have been conveyed by the image.

Without explicit dimensions the placeholder collapses and layout shifts when the image loads. Set both attributes (and corresponding inline style) so the cell reserves space whether or not the image ever arrives.

Outlook inserts a small gap below inline images. Apply style="display:block" on every <img> to eliminate that gap and ensure consistent vertical rhythm across all clients.

Older clients add a blue border around <a><img></a>. Set border="0" on the image attribute and style="border:0" inline so wrapped images render cleanly inside calls to action.

Email clients have no concept of "this page". Every image src must be an absolute https:// URL pointing to a publicly accessible CDN. Local paths, relative paths and http:// URLs (mixed content) silently fail to load.

Use a fast, geographically distributed image host. Some clients fetch images via proxies (Gmail) which add their own caching layer; first-party CDNs avoid hot-loading from a slow origin and ensure images load consistently across regions.

For hero backgrounds, pair the CSS background-image with a bgcolor matching the dominant tone. If the image is blocked, the cell still shows a sensible color, and text overlaid on the bgcolor remains legible — avoiding the white-text-on-white-block disaster.

Render images at 2x and downscale via width attribute so they look sharp on high-DPI displays: a 600x600 source displayed at width="300" height="300" appears crisp on Retina. The cost is bandwidth, so keep file sizes small with WebP-equivalent compression.

Animated GIFs work in most clients except Outlook (which shows only the first frame). Design the first frame so it makes sense as a static image — the headline, CTA, or key value must be readable even without the rest of the animation.

Why should critical copy (headings, CTA labels, prices) never be baked into images in an HTML email?

Treat images as enhancement, not the message. Use absolute https URLs, set width/height/display:block/border:0, write meaningful alt text, host on a fast CDN, pair backgrounds with bgcolor fallbacks, design 2x for Retina, and remember Outlook freezes GIFs on the first frame.