Why Your Email Images Look Broken in Half of Inboxes

Some inboxes simply do not load your images

Email clients have blocked remote images by default for a long time, for good reasons: loading an image from a sender's server tells that server you opened the message, roughly when, and something about where you were. Different clients handle this differently and the defaults shift over time. Some block until the reader clicks. Some load everything through a proxy so the sender learns very little. Some corporate gateways strip images entirely.

The consequence is that a meaningful share of your recipients will see the email's structure — text, buttons, layout — with rectangles where the photos should be. If the message only makes sense with the pictures, those people got nothing. If the offer, the date, the price or the call to action lives inside an image, those people got a blank.

The rule that follows is unglamorous and absolute: no essential information may exist only inside an image. Photos illustrate; text informs. Write the email so it works read aloud with the images off, then add the images to make it better.

Dark mode does unpredictable things to photographs

Dark mode in email is not one behaviour. Some clients leave your content alone and just darken the surrounding interface. Some invert or remap colours in your HTML while leaving images untouched, which produces a dark background with a photo that still has a bright white edge glued to it. Some apply a broader transformation that affects more than you expect. And the behaviour differs between the desktop and mobile versions of the same product.

The images that fail hardest are the ones with large flat white or very light backgrounds — cut-out product shots, logos on white, anything with a white border baked in. On a dark card, that white area glows like a light box and the object inside it floats disconnected from the design. Logos with black text on transparency are the other classic failure: the background goes dark, the text stays black, the logo disappears.

You can't control every client, so choose images that degrade gracefully. Mid-tone backgrounds survive far better than pure white or pure black. A product photographed on a mid-grey or warm neutral surface looks intentional in both light and dark mode. Where a photo genuinely needs a light background, giving it a soft mid-tone one instead is a small edit — Foxi AI can change the background behind a subject in a photo you already have while keeping the product's real colour and shape — and it removes a whole class of dark-mode ugliness.

Weight matters more in email than almost anywhere else

Email gets opened on patchy connections, on old phones, in transit. It also gets opened once, briefly. A photo that takes several seconds to appear has effectively not appeared, because the reader has already decided and moved on. And on metered mobile data, a heavy email is a small act of rudeness.

There is also a deliverability angle worth knowing about without overstating: very large messages can be truncated by some clients, which cuts off everything after a certain point, including your unsubscribe link. That is a real problem, not a cosmetic one.

Practically: use fewer, better images rather than many. Resize the file to roughly the dimensions it will actually display at rather than shipping a huge original and letting the email scale it down. Save at a quality setting where you cannot see artefacts at normal viewing distance, then stop — going further gains you little and costs a lot. And never build a text-heavy layout as one giant image, which fails both the blocking test and the weight test simultaneously.

Alt text is the image for a lot of your list

When images are blocked, most clients show the alt text in the space where the image would have been. That means your alt text is not an accessibility afterthought — it is the visible content for a real portion of your audience, and it is also what screen reader users hear.

Write it as a description of what the picture shows and why it is there, in a normal sentence. Not the filename. Not a keyword list. Not empty. If the image is a photo of a specific product, name the product. If it is decorative and adds nothing, an empty alt attribute is correct so screen readers skip it — but be honest about whether it truly is decorative.

Styling matters too: alt text inherits whatever text styling you give the image element in many clients, so setting a sensible font, size and colour on the image tag means the fallback looks deliberate rather than like a rendering fault.

Choosing photos that survive all of this

Once you account for blocking, inversion and compression, a pattern emerges in which photos hold up. Strong single subject, filled frame, mid-tone background, decent contrast between subject and background, and no fine detail that needs to be seen for the image to work. Wide scenic shots with the point somewhere in the middle distance fail, because at email width on a phone the point is four pixels across.

Avoid images that carry text as part of the picture, and avoid subtle gradients across large areas, which band badly after compression. Skin tones and food photography are worth a second look specifically in dark mode preview, since a colour shift there is more noticeable than on a product.

And accept a simple hierarchy: the email must work with no images, should look good with images in light mode, and must not look broken with images in dark mode. In that order.

• One clear subject, cropped close enough to read on a phone
• Mid-tone background rather than pure white or pure black
• No essential words, prices or dates inside the image
• Nothing that depends on fine texture or a subtle gradient
• Real alt text written as a sentence, styled so it looks intentional

Test before you send, and check current client behaviour

Every claim about how a specific email client renders images has a shelf life measured in months. Clients change their dark mode handling, their blocking defaults and their proxying behaviour without much fanfare, and the mobile app often behaves differently from the web version of the same service.

So do not take rendering rules from articles, including this one. Send yourself a test to accounts on the two or three services your list actually uses most, open each in both light and dark mode, and once with images off. That five-minute loop catches nearly everything. If you send at any volume, a rendering preview service is a reasonable expense.

Look at your own list data to decide which clients to test. There is no point perfecting rendering in a client three people use while ignoring the one used by half your subscribers.

Frequently asked