What is responsive email? Platform notes and checklist

What is responsive email? Build a usable baseline, then enhance it for the viewport

Responsive email is therefore not "make the desktop design smaller." It is the discipline of deciding what must reflow. It also decides what may simplify and what remains usable when a client ignores part of the responsive layer.

The 3 layers of responsive email

A useful mental model has 3 layers.

1. Fluid baseline

The base layout should already tolerate a range of widths. Common techniques include:

• containers that can shrink rather than relying on a fixed desktop width
• images constrained to their container
• text that can wrap naturally
• spacing that does not depend on a precise screen width
• buttons that remain usable when text wraps

This baseline matters because it is what survives when a media query is unsupported or stripped.

2. Media-query enhancement

A media query can change layout when the viewport reaches a threshold. Examples include:

• stacking 2 columns vertically
• increasing button width
• adjusting type size or spacing
• hiding a genuinely nonessential decorative element
• changing alignment from horizontal to centered

Gmail's CSS documentation includes standard media-query support, but email-client compatibility should still be tested rather than inferred from web-browser behavior.

3. Interaction and accessibility

A layout that technically fits the screen can still be poor on mobile. The CTA may be tiny, links crowded, text unreadably small, or important content visually reordered in a confusing way. Responsive design is about use, not merely width.

WCAG 2.2's target-size guidance provides a useful accessibility reference point: targets should generally be at least 24 by 24 CSS pixels, subject to stated exceptions. Email clients and inbox contexts are not identical to websites, but the principle is valuable: do not make a critical mobile action depend on precision tapping.

Fluid is not the same as responsive

A fluid email changes size continuously with its container. A responsive email can also change structure at defined conditions. Consider a product card with image on the left and copy on the right:

• at 640 pixels, a 2-column layout may be comfortable
• as the container narrows, fluid widths can reduce both columns
• at a chosen breakpoint, a media query can stack image above copy

The fluid behavior reduces pressure before the breakpoint. The media query changes the information layout when side-by-side content is no longer useful. That combination preserves a usable fallback when the client ignores the breakpoint rule.

Start with the narrow state mentally, even if you author desktop-first

Mobile-first email thinking does not require that every line of CSS literally starts from mobile. It means the design has answered the narrow-screen constraints early:

• What is the primary action?
• Which content should appear first?
• Can the product name wrap to 3 lines?
• What happens to a long localized CTA?
• Can a price and discount fit without shrinking to unreadable text?
• Does an image crop hide the product when it becomes narrow?

If these questions are solved only after a desktop layout is approved, the mobile version often becomes a compressed afterthought.

Stacking: preserve reading order

2-column layouts are common in ecommerce email, but the stacking order matters. A desktop row such as: image | product name + price + CTA usually becomes: image → product name → price → CTA on mobile. That is straightforward. Alternating editorial layouts are harder. If desktop rows alternate image-left/text-right and text-left/image-right, a naive source order can produce a confusing mobile sequence. Copy may appear before the wrong image, and the visual rhythm may break.

The solution is not merely CSS. It begins with source order and component semantics. Build the HTML so the linear reading order remains sensible before applying visual rearrangement.

Images: scale without making the message depend on cropping

A common baseline for raster images is to allow the image to shrink with its container while preventing it from exceeding its intrinsic or intended width. The exact CSS varies by component and client, but the principle is stable. Also plan for:

• high-density screens
• blocked images
• text embedded inside imagery becoming unreadably small
• aspect-ratio changes if the template uses crops
• file size on mobile networks

An image can resize perfectly and still fail as responsive content if all the offer text is baked into a graphic that becomes too small to read.

Buttons: width and hierarchy matter more than decorative precision

A mobile CTA should remain easy to identify and tap. Depending on the component, that might mean a full-width button or a generously padded inline-block button. Do not rely on a tiny text link for the primary action simply because it fits the desktop design. The fallback should remain a real link. Decorative effects such as rounded corners or shadows are secondary.

Hybrid techniques can help when media-query support is uneven

Some email developers use so-called hybrid or spongy techniques, where percentage-based tables, max-width constraints, and inline-block behavior create a layout that adapts even before a media query. These patterns can be valuable for specific compatibility targets.

But a technique is not automatically good because it is clever. Prefer a component that your team can understand, test, and maintain. The purpose of hybrid behavior is to protect the fallback, not to accumulate obscure markup.

Responsive design and dark mode are separate axes

A mobile email can render in light or dark mode. A desktop email can also render in either. Do not treat "mobile" as a proxy for dark mode or vice versa.

An audience-based test matrix samples combinations that matter to your audience rather than testing every possible permutation. For example:

• Gmail mobile, light and dark if the design is dark-sensitive
• Apple Mail mobile
• Outlook mobile
• representative desktop/web clients
• classic Outlook for components known to have legacy rendering constraints

Worked example

Suppose a campaign contains 2 product cards side-by-side inside a 600-pixel content area.

• Each card has:

• a 260-pixel image
• product name
• current price
• short description
• CTA

• A fragile approach hard-codes the 2 cards at 300 pixels each and assumes a media query will always stack them. If the media query is ignored on a narrow client, the row may overflow or force tiny scaling

• A stronger version works in layers:

• Baseline: each card cell can shrink, images use a fluid maximum width, text can wrap, and the total structure does not rely on fixed child widths that exceed the viewport

Enhancement: below the chosen breakpoint, the card cells become block-like/stacked, image width increases relative to the viewport, spacing changes, and CTA width grows. Fallback test: dizable the media query. If the 2 cards remain legible enough to understand and act on, the baseline is doing its job.

What passes and what does not

• When a layout feels cramped, the wrong first move is often to reduce the font size. A better sequence is:
• remove unnecessary horizontal competition
• allow content to stack
• reduce nonessential decoration
• adjust spacing
• then tune typography within a readable range
• Line length also matters. A wide desktop email should not force paragraphs to span the full container, while a mobile layout should avoid side padding so large that it leaves a narrow sliver for text

Common mistakes

1. If the layout is unusable without the breakpoint, the fallback is too fragile
2. Responsive design should change information layout when necessary, not just reduce dimensions
3. display:none can be useful for decorative material, but hiding meaningful price, terms, or CTA context creates content parity problems
4. This can force horizontal scrolling or unexpected clipping
5. Visual rearrangement cannot always rescue a confusing linear reading order
6. Email CSS support is client-specific. Test delivered HTML in representative inboxes

Questions we get asked