Skip to main content

Fixing Gmail App Media-Query Stripping on Android and iOS

Build a fluid hybrid email layout that stays responsive in the Gmail app when @media and style blocks are stripped for non-Gmail accounts on Android and iOS.

Your responsive template works in every preview, then a customer using the Gmail app with an Outlook or Yahoo address sees a desktop-width layout crammed onto a phone, with no stacking and no breakpoints. The Gmail app stripped your <style> block. This guide shows the fluid layout that stays responsive even when media queries never run.

Root cause: GANGA strips embedded styles

The Gmail app behaves differently depending on which account is signed in. With a proper Gmail or Google Workspace account, the app supports a <style> block in <head> and your @media rules execute. But when the Gmail app is configured with a non-Gmail account — an Outlook.com, Yahoo, or generic IMAP address — it runs in the mode developers call GANGA (Gmail App using Non-Google Accounts). In GANGA, the app strips embedded <style> blocks entirely.

Once the <style> is gone, every rule inside it is gone too: your @media (max-width:600px) stacking rules, your display:none toggles, your width overrides. The layout falls back to whatever the raw HTML structure dictates. If that structure is a fixed-width width="600" table, GANGA renders it at 600px on a 375px-wide phone and the user pans sideways to read.

The mistake is depending on media queries for layout. The fix is a layout that is already responsive from its HTML structure alone, with media queries layered on top only as enhancement. This is the foundation of robust responsive email layouts and a core competency in Mastering Email HTML & CSS.

Fluid hybrid layout without media queries Two inline-block columns sit side by side on desktop and wrap to stacked full-width blocks on mobile with no @media rule. Fluid Hybrid Layout: Wraps Without @media DESKTOP (wide container) Col A max-width:280 Col B inline-block MOBILE (narrow container) Col A width:100% Col B wraps below → The narrowing container wraps inline-blocks automatically; no @media rule is required.
A fluid hybrid layout uses max-width plus width:100% inline-blocks so columns wrap on a narrow screen even when the Gmail app strips every style.

The exact fix: a fluid hybrid ("spongy") layout

The pattern relies on two columns that are inline-block, each capped with max-width and set to width:100%. On a wide container they sit side by side; on a narrow container they cannot both fit, so the second wraps under the first — pure flow, no media query. Because Outlook for Windows (Word engine) ignores display:inline-block and max-width, it gets a parallel MSO ghost table that holds the two columns side by side, hidden from every other client.

<!-- Outer fluid container: fills the viewport up to 600px, centers above that. -->
<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center">

      <!--[if mso]>
      <!-- Outlook desktop ghost table: gives Outlook fixed 600px width and a 2x280
           column grid, since it ignores max-width and inline-block. align=center
           keeps it centered like the fluid container does for everyone else. -->
      <table role="presentation" width="600" cellpadding="0" cellspacing="0" align="center"><tr><td>
      <![endif]-->

      <!-- The real fluid wrapper. max-width caps it on desktop; width:100% lets it
           shrink on mobile. Gmail app (GANGA) keeps this because it is an inline
           style attribute, not a <style> rule. -->
      <div style="max-width:600px;margin:0 auto;">

        <!--[if mso]><td width="280" valign="top"><![endif]-->
        <!-- Column A: inline-block + max-width is the responsive engine. On a phone
             the container is < 560px so column B cannot fit beside it and wraps. -->
        <div class="col"
             style="display:inline-block;width:100%;max-width:280px;vertical-align:top;">
          <table role="presentation" width="100%" cellpadding="0" cellspacing="0">
            <tr><td style="padding:12px;font-family:Arial,sans-serif;font-size:15px;color:#334155;">
              Column A content
            </td></tr>
          </table>
        </div>
        <!--[if mso]></td><td width="280" valign="top"><![endif]-->

        <!-- Column B: same recipe. Two 280px inline-blocks (+padding) exceed a phone
             width, so B drops below A with zero media queries involved. -->
        <div class="col"
             style="display:inline-block;width:100%;max-width:280px;vertical-align:top;">
          <table role="presentation" width="100%" cellpadding="0" cellspacing="0">
            <tr><td style="padding:12px;font-family:Arial,sans-serif;font-size:15px;color:#334155;">
              Column B content
            </td></tr>
          </table>
        </div>
        <!--[if mso]></td><![endif]-->

      </div>

      <!--[if mso]>
      </td></tr></table>
      <![endif]-->

    </td>
  </tr>
</table>

The responsiveness lives entirely in the inline style attributes, which GANGA preserves because it only strips <style> blocks, not style="" attributes. When the available width drops below roughly two columns plus padding, the second inline-block has no room and flows underneath. No @media rule fires; the layout simply reflows.

Media queries then become progressive enhancement — they refine the spongy base for clients that do support them, but nothing depends on them:

<!--[if !mso]><!-->
<style>
  /* Enhancement only. If the Gmail app (GANGA) strips this, the inline-block
     layout above still reflows. These rules just polish supporting clients. */
  @media only screen and (max-width:600px) {
    .col { max-width:100% !important; }   /* iOS Mail / Apple Mail: full-bleed columns */
    .pad { padding:8px !important; }       /* tighten spacing on small screens */
  }
</style>
<!--<![endif]-->

Because the layout no longer needs that block to survive, you also avoid the inliner trap where the rules get dropped during the build — though it is still worth following preserving media queries when inlining with Juice so the enhancement layer stays intact for clients that can use it.

Variant: Gmail proper vs GANGA vs Apple Mail

  • Gmail proper (Google account): Supports a single <style> block in <head>. Your @media enhancement runs, so columns get full-bleed padding refinements. The spongy base also works, so this client is doubly covered.
  • GANGA (non-Google account in the Gmail app): Strips the <style> block. Only the inline style attributes survive, so the fluid hybrid is the only thing keeping it responsive. This is the client the whole pattern exists for.
  • Apple Mail / iOS Mail: Full CSS support, honors @media and max-width. The spongy base plus the enhancement layer both apply; this is your highest-fidelity render.

The single layout serves all three without branching, because the base degrades gracefully and the enhancement is purely additive.

Pipeline integration

  1. Keep the MSO ghost-table comments in your source — never let an HTML minifier strip comments, or Outlook desktop loses its grid.
  2. Author columns as reusable partials so the inline-block + max-width recipe is identical everywhere.
  3. Inline with removeStyleTags:false so the enhancement block reaches Gmail proper and Apple Mail.
  4. Run a render in Litmus/Email on Acid specifically against the Gmail app with a non-Gmail account, since that is the only way to exercise GANGA.

Validation checklist

  • Columns use display:inline-block; width:100%; max-width:<n>px as inline style attributes, not <style> rules
  • Two columns plus padding exceed a phone width so the second wraps without any @media
  • MSO ghost table (<!--[if mso]>) gives Outlook desktop a fixed-width side-by-side grid
  • @media rules are wrapped in <!--[if !mso]> and treated strictly as enhancement
  • Layout reflows correctly in the Gmail app with a non-Gmail (GANGA) account on Android and iOS
  • Layout renders side-by-side in Outlook 2016/2019/365 and stacked in iOS Mail / Apple Mail / Samsung Email
  • HTML minifier in the build preserves conditional comments

Gmail proper vs. GANGA: what actually differs

It is worth being precise about the two modes, because the difference dictates every design decision here. Gmail proper means the Gmail app (or webmail) signed in with a Google account — @gmail.com or a Google Workspace domain. In this mode Gmail runs its own sanitizer that supports a single <style> block in <head>, prefixes your class names, and executes @media queries. Your responsive breakpoints fire.

GANGA — Gmail App using Non-Google Accounts — is the same app binary configured with an Outlook.com, Yahoo, AOL, or generic IMAP/POP account. Google does not route these messages through the same rendering path; instead the app uses a stricter sanitizer that removes <style> blocks wholesale. The visible consequence is identical to a client with no CSS support at all: only style="" attributes survive. Critically, this is decided by the account, not the device — the same phone shows your @media rules working on the user's personal Gmail and stripped on their work Outlook address. That is why you cannot detect or branch around it server-side; the only safe assumption is that embedded styles may vanish for any given recipient.

A second subtlety: GANGA does not merely ignore @media, it removes the entire block, so any display:none hiding rules, dark-mode overrides, or font bumps you parked in <style> are gone too. Anything that must render has to live inline.

More variant cases

Case: a three-column footer. Three inline-block cells at max-width:180px (plus padding) total well over a phone width, so on a narrow GANGA container they stack one-per-row automatically. On a tablet-width container two may sit side by side with the third wrapping — acceptable, and identical to how the fluid base behaves everywhere. Give Outlook a three-<td> ghost table to hold them in a row.

Case: an image + text card that must not split. Keep the image and its caption inside the same inline-block column so they wrap together. If you place the image in one cell and text in a sibling cell, GANGA may wrap them independently and orphan the caption. The unit of reflow is the inline-block, so make each card one block.

Case: a right-aligned CTA on desktop, centered on mobile. Do not rely on a media query to re-center. Set the inline style="text-align:center" on the cell as the base (centered everywhere, including GANGA) and use the @media (min-width:600px) enhancement to push it right only on clients that execute queries. The base must be the mobile-correct state because GANGA gets the base.

Case: hiding a desktop-only spacer. display:none in <style> will not run in GANGA, so a spacer you intended to hide stays visible. Either size the spacer in a way that is harmless when shown, or move it into an <!--[if mso]>-only block if it exists purely for Outlook.

Whitespace gap between inline-blocks

One GANGA-specific gotcha: inline-block elements render the literal whitespace between tags as a visible gap, which can push your second column past the wrap threshold prematurely or leave a sliver of space. Eliminate it by closing the first </div> and opening the next <div with no whitespace between them, or by setting font-size:0 on the parent wrapper and restoring font-size on the children:

<!-- Parent: font-size:0 collapses the inter-block whitespace that GANGA would otherwise show -->
<div style="max-width:600px;margin:0 auto;font-size:0;">
  <!-- Each column restores its own font-size; width:100%+max-width drives the wrap -->
  <div class="col" style="display:inline-block;width:100%;max-width:280px;
       vertical-align:top;font-size:15px;">Column A</div><div class="col"
       style="display:inline-block;width:100%;max-width:280px;
       vertical-align:top;font-size:15px;">Column B</div>
</div>

Deeper pipeline integration

  1. Lint for the anti-pattern. Add a CI grep that fails the build if a <style> block contains display:none or width overrides without an inline equivalent — that is exactly the content GANGA discards. Catching it in CI is cheaper than a Litmus round-trip.
  2. Inline with removeStyleTags:false. The enhancement block must reach Gmail proper and Apple Mail, so the inliner copies matching rules to inline attributes and keeps the <style> for media queries. See preserving media queries when inlining with Juice.
  3. Preserve comments through minification. The MSO ghost table is comment-wrapped; a comment-stripping minifier silently removes Outlook's grid. Configure the minifier to keep conditional comments.
  4. Test the real path. Litmus and Email on Acid both expose "Gmail App (Android) IMAP" / "Gmail App (iOS) non-Google" render targets — those are the only ones that exercise GANGA. A Gmail-proper preview will look perfect and tell you nothing about the failure mode this guide addresses.
  5. Snapshot it. Capture the GANGA render in your visual-regression suite so a future template change that re-introduces a media-query dependency is caught automatically.

← Back to Responsive Email Layouts