Skip to main content

Preventing Font-Size Inflation in iOS Mail and the Gmail Android App

Stop mobile clients enlarging small text per block: text-size-adjust on iOS, the 14px floor that avoids Android inflation, and why one paragraph grows and its neighbour does not.

A footer set at 12px renders at 12px on desktop and at something closer to 16px on a phone — but only in some paragraphs, leaving a disclaimer larger than the body copy above it. This guide covers what triggers that enlargement, the one property that disables it, and the design rule that avoids it entirely.

Root Cause: Readability Heuristics Operating Per Block

Mobile clients inherited a browser feature intended for desktop-designed web pages viewed on a small screen. When a block of text would render below a readability threshold, the engine scales it up so the reader is not asked to pinch and zoom.

Two properties of that behaviour make it disruptive in email. It operates per block, so a page can end up with one paragraph enlarged and the paragraph beside it untouched, which reads as a bug rather than as a feature. And it is not proportional to your scale — the engine chooses a factor from its own readability model, so the relationship between your 12px caption and your 16px body is not preserved. A carefully built type hierarchy can invert.

The threshold differs by platform and is not documented as a fixed number. In practice, text below roughly 13px is at risk on iOS, and the Gmail Android app and Samsung Email apply their own thresholds in a similar region.

Type hierarchy disrupted by per-block inflation A designed hierarchy of 16 pixel body copy over 12 pixel caption text inverts when the caption block alone is enlarged by the client. Inflation Does Not Preserve Your Hierarchy as designed body copy — 16px caption — 12px disclaimer — 12px Clear ordering, three steps apart. after inflation body copy — unchanged caption — enlarged past body disclaimer — untouched One block grew; its neighbour did not.
The inconsistency between neighbouring blocks is what makes inflation read as a rendering bug rather than as an accessibility feature.

The Exact Fix

Two measures, applied together. The property handles iOS; the size floor handles the platforms where no property does.

<!-- On the outer wrapper: stops iOS Mail and Safari-derived views from
     rescaling text blocks. -webkit- prefix is required; the unprefixed form
     is not honoured by the clients that need it. -->
<body style="margin:0; padding:0; -webkit-text-size-adjust:100%; -ms-text-size-adjust:100%;">
  <table role="presentation" width="100%" cellpadding="0" cellspacing="0" border="0"
         style="-webkit-text-size-adjust:100%;">
    <tr>
      <td style="font-family:Arial,sans-serif;
                 font-size:16px;          /* body: never below 14px */
                 line-height:24px;
                 mso-line-height-rule:exactly;">
        Body copy.
      </td>
    </tr>
    <tr>
      <td style="font-family:Arial,sans-serif;
                 font-size:14px;          /* smallest size used anywhere */
                 line-height:20px;
                 mso-line-height-rule:exactly;
                 color:#4f5e70;">          <!-- darker, since it is small -->
        Legal disclaimer text — at 14px, no client's threshold is triggered.
      </td>
    </tr>
  </table>
</body>

The property must be declared on the wrapper as well as the body, because several clients strip or rewrite the <body> element entirely and replace it with a container of their own. Declaring it only once, on an element that may not survive, is the most common reason the fix appears not to work.

The 14px floor is the more robust half. The Gmail Android app does not reliably honour text-size-adjust, and Samsung Email applies its own scaling; neither offers a property that switches the behaviour off. Staying above the threshold is the only approach that works on those platforms, and it is better typography anyway — 12px legal text on a phone is close to unreadable, which is precisely why the client is enlarging it.

Variant: When Small Text Is Genuinely Required

Occasionally a design calls for text below the floor — a superscript marker, a table of dense figures. Two approaches keep it stable.

Options for dense content A media query that raises the size on mobile keeps control with you, while rendering dense material as an image trades inflation risk for image blocking. Control the Enlargement Yourself raise it in a media query you choose the mobile size Works wherever the query survives; the base size still clears the floor. render it as an image no text for the engine to scale Trades inflation for image blocking — only for supplementary content.
Both options keep the rendered size under your control; neither involves declaring a size the client will override.

Give the block an explicit larger size on mobile through a media query, so you control the enlargement rather than the client: @media (max-width: 480px) { .dense { font-size: 14px !important; } }. In clients that read the query, your value wins; in those that do not, the underlying size is still above the threshold if you set the base sensibly.

Alternatively, render genuinely dense material as an image with proper alt text. This trades one set of problems for another — images are blocked by default in several clients — so it is appropriate only where the content is supplementary rather than essential.

Client response to the text-size-adjust property iOS Mail honours the property, the Gmail Android app does not reliably, and Samsung Email applies its own scaling regardless. The Property Only Covers One Platform iOS Mail, Apple Mail honours the property Declare it on both body and wrapper, prefixed. fully controllable Gmail Android app unreliable Behaviour varies by account type and app version. rely on the size floor Samsung Email no property at all Applies its own scaling with no opt-out. the floor is the only fix
Only one of the three platforms can be switched off with a property, which is why the size floor rather than the declaration is the primary defence.

Why the Floor Is Better Than the Property

It is tempting to treat text-size-adjust as the real fix and the size floor as a fallback. In practice the priority is the other way round, for three reasons.

Coverage. The property addresses one platform family. The floor addresses every platform, including the two that offer no opt-out at all and any future client that adopts the same heuristic. A defence that depends on a property is only as good as the list of clients that honour it, and that list is not under your control.

Failure mode. When the property is stripped — and it can be, since several clients rewrite inline styles on the elements it needs to sit on — the text reverts to being small enough to trigger enlargement, so the failure is silent and the layout breaks. When the floor is in place and the property is stripped, nothing happens, because there was nothing to enlarge.

Reader experience. The heuristic exists because small text on a phone is genuinely hard to read. Suppressing it with a property leaves the reader with the unreadable text the client was trying to fix; raising the size solves the underlying problem. For transactional mail in particular — receipts, confirmations, security notices that people read carefully — the accessible outcome and the stable outcome are the same one.

Ship both. The property gives you predictable rendering on the platform where it works, and the floor makes the design correct everywhere else. What you should not do is treat the property as permission to keep 11px text in the template, which is the most common way this fix is applied and the reason it so often appears not to work.

Pipeline Integration

Encode the floor as a build-time check rather than as a guideline. A lint pass over compiled output that fails on any font-size below 14px catches the regression the moment it is introduced and removes the need for anyone to remember the rule.

Keep the floor in the type scale itself: if the smallest token is 14px, no template can go below it without stepping outside the system, which is a visible thing to do in review.

Validation and Deployment Checklist

Frequently Asked Questions

Why does only one paragraph grow?

Because the heuristic runs per block. The engine evaluates each text block against its readability threshold independently, so a block at 12px is enlarged while an adjacent one at 15px is not. This is also why the effect is often reported as intermittent — it depends on which sizes happen to sit either side of the threshold.

Does text-size-adjust: none work better than 100%?

No, and it is worse. Some engines treat none as an accessibility violation and ignore it, and it also disables the user's own ability to scale text, which is a genuine accessibility feature. 100% says "render at the authored size" without removing user control.

It is larger than print convention, but email is read at arm's length on a small screen, and the client will enlarge smaller text anyway — so the choice is between 14px that you control and something around 16px that you do not. Reducing the visual weight with a muted colour, within contrast limits, achieves the hierarchy without dropping the size.

How do we test for inflation without a device lab?

A real device is best, but a browser emulator gets most of the way there: open the compiled HTML in a mobile viewport with the desktop user agent overridden, and compare the computed font sizes against the authored ones. Any block whose computed size differs from its declared size is being adjusted. That check catches the iOS case reliably; the Android variants need a real device or a client render farm, because the enlargement is applied by the mail app rather than by the underlying engine.

Does this affect preheader text?

Preheader text should be hidden rather than small — a zero-height container with display:none fallbacks, not a 1px font size in a visible block. A tiny but visible preheader is exactly the input that triggers inflation, and the result is a line of preview text rendered at full size at the top of the message.

← Back to Email Typography and Web Fonts