Graphics in Emails: Sizing, Formats & Deliverability

More graphics don't automatically make an email better. They can improve attention and clicks, but they can also slow rendering, trigger deliverability concerns, hide important content behind Gmail clipping, and make open-rate data less reliable. For lifecycle and transactional messages, the right question isn't “How can we make this email more visual?” It's “Which graphics improve comprehension without becoming a dependency?”

That distinction matters in welcome, activation, billing, churn-save, and win-back sequences. A newsletter can sometimes tolerate a decorative failure. A payment notice or activation prompt can't. The email needs to communicate its purpose, preserve its CTA, and remain accessible even when images are blocked, clipped, inverted, or rendered differently across inboxes.

Table of Contents

• Why Graphics in Emails Are a Deliverability Decision
• How Image Loading Distorts Your Open Rate Data
• What to use instead of open rate alone
• File Size Limits and Format Rules That Prevent Clipping
• Practical limits for common assets
• A safer export sequence
• Accessibility Requirements When Images Are Blocked
• Build the fallback first
• Rendering Differences Across Email Clients and Dark Mode
• Compare the failure modes
• Building an Image Optimization Workflow for Lifecycle Teams
• Start with the message contract
• Batch the technical work
• Test the journey, not only the template
• Pre-Send Testing Checklist for Email Graphics

Why Graphics in Emails Are a Deliverability Decision

A polished hero image can support brand expression, but it can also create operational problems when it dominates the message. High image density reduces visible HTML text, may create spam-like signals, and can slow loading for recipients on constrained connections. Guidance from MoEngage's email HTML best practices recommends compressing assets, avoiding a single large hero image with minimal text, and maintaining a 60/40 text-to-image balance.

That balance isn't a design law. It's a useful risk-control principle. If a recipient sees only blank image boxes, the email loses its subject line equivalent inside the message. The activation instruction disappears. The billing explanation becomes unclear. The unsubscribe path may sit below content that Gmail clips.

A lifecycle team should judge every graphic against three questions:

• Does it clarify the message? A product screenshot can make a feature prompt easier to understand. A decorative gradient rarely earns the same operational cost.
• Does the email work without it? Live HTML text should carry the promise, context, and CTA.
• Can the asset survive the inbox? File weight, format support, dark mode behavior, and client-specific rendering all matter.

Practical rule: Treat every image as conditional content. The email must remain useful when the image request never happens.

This is why graphics in emails deserve a place in deliverability reviews, not just creative reviews. Teams working on activation or churn-save flows also need to consider that their audiences may have different inbox settings, devices, and client environments. A design that looks excellent in one preview can fail for a meaningful part of the audience without producing an obvious error in the sending platform.

Before changing a template, review the broader email deliverability practices for lifecycle programs. The practical standard is simple: use visuals to reinforce the message, never to carry the only version of it.

How Image Loading Distorts Your Open Rate Data

Modern open tracking depends on a tiny invisible image, usually a 1×1 pixel. When the recipient's email client requests that image, the sender's system records an open. The metric therefore measures a graphics-loading event, not proof that a person read or understood the email. The technical history is documented in this analysis of email marketing measurement.

When images are blocked, the recipient can read every word while the tracking request never occurs. The sender records no open. The opposite problem can also occur when a client downloads images automatically without a person meaningfully reading the message. The reported number can move in either direction because the measurement layer is attached to image behavior.

This creates a serious problem for lifecycle analysis. Suppose a team tests two subject lines in an activation sequence. If one audience segment blocks more images than another, the open-rate comparison may reflect client settings rather than subject-line quality. A win-back message can appear ignored even when recipients read it, while a message opened automatically can look more successful than its downstream clicks suggest.

What to use instead of open rate alone

Open rate still has diagnostic value when tracked consistently within a comparable audience, but it shouldn't stand alone. Pair it with metrics that require a more deliberate action:

• Click activity: A click shows that the recipient interacted with a destination, although it still doesn't explain the full motivation.
• Conversion events: Activation, feature use, payment completion, or subscription recovery connect the email to the behavior the journey was designed to influence.
• Replies and direct responses: These can reveal intent that pixel data can't capture.
• Audience and client context: Compare performance only after accounting for meaningful differences in inbox and device behavior.

Apple's privacy features add another layer of complexity for marketers interpreting opens. The practical response isn't to abandon measurement. It's to stop treating a tracking pixel request as a complete engagement record. Teams should optimize the message for clicks and outcomes, then use open data as one imperfect signal among several. For related privacy considerations, see this explanation of private relay and Apple ID email behavior.

File Size Limits and Format Rules That Prevent Clipping

Gmail clipping is one of the least visible ways a graphic can damage an email. When the HTML exceeds 102 KB, Gmail can hide the remainder of the message, including CTAs, legal copy, and unsubscribe links. Mailjet's guidance on HTML size and image dimensions identifies the 102 KB HTML limit and recommends keeping individual images under 200 KB.

The fix isn't “compress everything.” Start by reducing unnecessary markup, repeated inline styles, and oversized encoded assets. Then export each image for its actual role. A photographic product scene usually suits JPEG. A graphic with transparency or sharp interface details may suit PNG. WebP can be useful where your sending and recipient environments support it, but broad compatibility should take priority over theoretical compression gains.

Animated GIFs need separate handling. Keep them under 1 MB, and make the first frame useful because some Outlook versions display only that frame. A GIF that reveals the core instruction only after animation has started is not a reliable lifecycle asset.

Practical limits for common assets

The 600-pixel width is a common structural limit for HTML email layouts, and images wider than that may fail to fit reliably across clients, as described in this email image sizing guidance. Scale the source asset for its display context rather than inserting a large file and relying on the inbox to resize it.

A safer export sequence

1. Crop before compressing. Remove empty canvas and unnecessary visual detail.
2. Choose the format by content. Use JPEG for photographs, PNG for transparency and crisp UI elements, and GIF only when motion adds meaning.
3. Compress in batches. Keep naming and dimensions consistent across journey variants.
4. Inspect the final HTML. Images aren't the only source of weight. Template code can push the message over the clipping threshold.
5. Keep copy live. Never place the complete CTA or transactional explanation inside the hero asset.

The result should feel intentional, not stripped down. A small, sharp screenshot paired with live explanatory text usually performs a safer job than one cinematic image carrying the entire email.

Accessibility Requirements When Images Are Blocked

Image blocking isn't only a rendering inconvenience. It changes whether a recipient can understand the message at all. The W3C guidance for informative images says every informative image needs a short text alternative, and that alternative should include words embedded in the image when those words carry meaning.

Write alt text for the recipient, not for the designer. “Dashboard screenshot” tells someone very little. “Dashboard showing the new team permissions panel” provides context. If the screenshot contains a meaningful label, include that label in the alternative so the text-only experience preserves the same decision-making information.

Decorative images require the opposite treatment. An ornamental divider, background texture, or purely atmospheric shape should use an empty alt attribute, so assistive technology doesn't force the recipient through irrelevant description. A linked graphic also needs meaningful link text, either through surrounding live text or an accessible label that explains the destination.

Build the fallback first

Draft the email with images disabled before polishing the visual version. The fallback should retain:

• The purpose: The recipient should know why the message arrived.
• The instruction: The next action should remain explicit.
• The CTA: Use a live text link or HTML button, not text baked into an image.
• The hierarchy: Headings, paragraphs, and links should preserve the intended reading order.
• The context: A missing product screenshot shouldn't erase the explanation around it.

Animated GIFs need an additional safeguard. Put the key message in the first frame because some Outlook versions show that frame instead of playing the animation. Motion can add interest, but it can't be the only way the recipient discovers the offer, feature, or instruction.

The accessible email guidance from Litmus also emphasizes the risk of image-only messages, particularly when clients block graphics or render them inconsistently. Accessibility improves operational resilience because the same text-first structure helps screen-reader users, image-blocked recipients, and clients that fail to load remote assets.

For compliance considerations around consent, identification, and unsubscribe handling, use this resource on email marketing compliance. A compliant email still needs to be understandable when its visual layer disappears.

Rendering Differences Across Email Clients and Dark Mode

Email clients don't share one rendering engine. Gmail in a browser, Outlook desktop, Apple Mail on mobile, and dark mode settings can interpret the same asset differently. A rounded corner may survive in one environment, while a gradient, transparency layer, or background color changes elsewhere.

Use conservative construction for high-stakes emails. Standard <img> tags are generally safer than SVG because some inbox providers block SVG rendering, and ordinary JPEG, PNG, and GIF assets offer broader support. Keep important contrast in live HTML, where you can control fallback colors and text behavior more reliably.

Compare the failure modes

• Gmail web: Remote images may not appear until the client permits loading, and oversized HTML can be clipped. A design should expose its message before either event.
• Outlook desktop: Rendering limitations can affect gradients, animated GIF playback, and modern CSS patterns. The first frame and plain structure matter.
• Apple Mail mobile: It often handles rich imagery well, but that makes it a poor sole testing environment. A forgiving client won't reveal failures elsewhere.
• Dark mode: Some environments invert colors or alter backgrounds. Transparent logos, dark text, and image edges can disappear into the surrounding interface.

A transactional email should use fewer fragile effects than a promotional campaign. A payment receipt needs readable amounts and instructions in live text. A billing notification shouldn't depend on a carefully controlled background image to establish contrast.

For a practical visual reference on how the same design can change by client and theme, watch this email rendering walkthrough.

Responsive behavior also matters. Set width constraints so the graphic scales within the available viewport, but don't depend on CSS that a particular client may ignore. Test both the loaded and blocked versions, then inspect dark mode as a separate state rather than assuming it will preserve the original palette.

Building an Image Optimization Workflow for Lifecycle Teams

A repeatable process prevents graphics from becoming a last-minute source of broken sends. The workflow should begin before design, when the team decides which information belongs in HTML and which information benefits from a visual.

Start with the message contract

For each journey email, record the required subject, CTA, supporting explanation, legal elements, and fallback behavior. In a welcome email, the product screenshot may support orientation. In a dunning email, payment instructions and account status should remain fully readable without any image.

Then create a small asset brief with the intended width, format, file-size target, alt text, link destination, and dark mode expectation. This reduces the chance that a designer exports a beautiful asset that the template can't safely use.

Batch the technical work

Export related assets together, compress them in one pass, and store the approved versions with clear names. Keep source files separate from send-ready files. Host linked images on infrastructure your team controls, using stable public URLs and predictable paths. A third-party image host can work, but it adds another dependency that can fail, change access rules, or make asset governance harder.

At the template stage, add alt text and verify that every clickable graphic has a clear destination. Keep live copy outside the image, and check total HTML weight after the final personalization and conditional blocks are included.

Test the journey, not only the template

A lifecycle email can contain dynamic names, event-based blocks, pricing fields, and variant logic. Test representative versions, including the longest copy and the heaviest image combination. Mara is one option for teams that want an AI email marketer to draft and operate lifecycle journeys from product and payment events with approval controls, but the same image workflow applies whether a team uses an agent, a CRM, or custom templates.

Finish with a record of what passed, what changed, and which client still needs a fallback. That history makes future updates faster and stops teams from solving the same Outlook or clipping issue repeatedly.

Pre-Send Testing Checklist for Email Graphics

Before sending a lifecycle or transactional email, run the message through this compact review:

• Size: Confirm total HTML stays under 102 KB, and individual images stay under 200 KB, using Mailjet's email size guidance.
• GIFs: Confirm animated assets stay under 1 MB and that the first frame communicates the essential point.
• Structure: Verify that live HTML contains the headline, explanation, CTA, and unsubscribe path.
• Accessibility: Check every informative image for descriptive alt text, every decorative image for an empty alt attribute, and every linked graphic for meaningful link text.
• Clients: Preview Gmail, Outlook desktop, and Apple Mail on mobile. Include dark mode states.
• Blocked images: Disable image loading and complete the email's intended action. If you can't understand or use it, the recipient can't either.
• Width and format: Check that assets fit the 600-pixel layout constraint and avoid unsupported SVGs where compatibility matters.
• Metrics: Define click and conversion measures before launch so open-rate distortion doesn't become the only verdict.

For high-stakes dunning, churn-save, and activation messages, this review should happen before every material template change. A short pre-send check is cheaper than discovering after launch that the CTA was clipped, the screenshot was unreadable, or the message became empty when images were blocked.

Mara helps software teams draft, run, and maintain lifecycle emails for welcome, activation, feature adoption, dunning, churn-save, and win-back journeys, with approval controls before sending. Visit Mara to see how product and payment events can drive relevant email sequences without making your team maintain every journey manually.