Diagnosing Gmail rendering issues

Quick answer: Almost every one of the Gmail rendering issues you will meet is one of two failures. Either Gmail’s sanitizer removed CSS it disapproved of, or Gmail cut the message off at a size limit. That limit is roughly 102 KB on desktop and as little as 20 KB in the iOS app. Work out which of the two happened before you touch a single line of code, because the fixes have nothing in common. Everything else is images, dark mode, and your ESP quietly rewriting things behind your back.

The support message I get more often than any other goes something like this. “It looks fine in Gmail, but a chunk of the list says it’s broken.” Then a screenshot arrives, and the layout is rubble. Both statements are true at the same time. That’s the annoying part. Because “Gmail” isn’t one thing. It’s a family of environments with measurably different CSS support, sharing a logo. An email can be perfect in four of them and demolished in the fifth. If you tested in the four, you tested nothing useful. This guide is about Gmail rendering issues specifically – what breaks, why, and what each fix costs you to maintain. If you want the wider view across every client, the pillar piece on email rendering issues sorts the whole inbox by rendering engine. This page goes one level down, inside Gmail, where the rules are stranger.

Strip or clip: the two-minute triage for Gmail rendering issues

Before you open the HTML, work out which failure you’re looking at. It takes about two minutes and saves the afternoon.

Two things go wrong in Gmail far more than anything else. The sanitizer eats your CSS, or the byte limit eats your email. They look different in the inbox. They have completely different fixes.

Three questions that narrow it down

Run these in order. Stop at the first yes.

Is there a “[Message clipped] View entire message” link at the bottom? Then it’s size. Go to the clipping section. Nothing else matters until that’s sorted.
Is the layout intact but the styling gone? Wrong fonts, no colours, everything shoved left. That’s the sanitizer dropping your <style> block.
Does it break in one Gmail and not another? Then it’s an environment problem, and the next section is the one you want.

That’s it. Three questions, and you’re on the right half of this page.

If none of them fit, it’s usually images, dark mode inversion, or your sending platform. All covered further down.

The thing it almost never is

Gmail rendering issues are almost never “Gmail was having a bad day”.

Gmail is aggressive, and it changes things without telling anyone. It is not capricious. The same email, sent to the same account type, breaks the same way every time. People burn hours on the assumption that it’s random, and it isn’t.

When something really does look random, it’s usually one of four things. A different account type than you assumed. Your ESP rewriting the HTML at send time. The image proxy serving a cached version. Or an email that clips on one send and not the next, because it’s sitting right on the limit.

None of those are Gmail being moody. All of them are findable.

Gmail is not one email client, it’s five environments

This is the reframe that makes the rest of the page make sense. Once you have it, most Gmail rendering issues stop being mysterious.

You are not testing “Gmail”. You are testing up to five separate rendering situations, and they don’t agree with each other.

The five Gmail environments

Environment	Embedded `<style>`	Media queries	The thing to remember
Gmail web	Supported, head only	Yes	Classes get renamed with an `m_` prefix, sanitizer still strips whole categories of CSS
Gmail app, Android, Google account	Supported	Yes	Broadly matches web, but check it separately anyway
Gmail app, iOS, Google account	Supported	Yes	Tightest clipping behaviour of the lot
GANGA (Gmail app, non-Google account over IMAP)	Not supported at all	No	Everything critical must be inline, or it does not exist
The “View entire message” view	`<style>` tags removed	Effectively no	Gmail’s own rendering of a clipped message

GANGA is the acronym the email community landed on years ago. Originally Gmail Android with Non-Gmail Accounts. Then Email on Acid found the iOS app had inherited exactly the same flaws, so it quietly became Gmail App with Non-Google Account. The subpar CSS support survived the rename.

Someone reading your email in GANGA sees no embedded styles whatsoever. No media queries. No opacity. And no background images through CSS or the HTML attribute, which I’ll come back to, because it’s the one case where there genuinely is no workaround.

And the last row of that table deserves a moment. The “View entire message” view is Gmail’s own re-render of a clipped message, with <style> tags stripped. Your subscriber sees that version at the exact moment they decided to make an effort.

Why GANGA is probably about to matter more

Here’s the bit nobody in email development seems to have picked up on yet.

Google is retiring Gmailify and POP fetching. Per Google’s own support documentation, the feature stopped supporting new users after the first quarter of 2026. Existing users can carry on until January 2027. After that, affected people are pointed at a standard IMAP connection in the Gmail app.

Now think about what Gmailify was doing for rendering. A Gmailified account was pulled properly into Google’s own infrastructure rather than just being read over IMAP, which is why it got Gmail’s spam filtering, categories and search. My understanding is that it rendered like a Google account too – embedded styles working, media queries firing – though I’ll be upfront that I’m reasoning from how the accounts were plumbed rather than from a controlled test I ran at the time. Nobody documented GANGA versus Gmailify rendering side by side, as far as I can find.

What is not in doubt: a plain IMAP connection in the Gmail app is GANGA. No embedded styles. No media queries.

So the least capable Gmail environment may be about to grow its share, for the first time in about a decade. Every article that says “just inline the important bits, embedded styles are fine now” gets a little less true.

I could be wrong about the scale of this. That sentence is doing real work, so I’ll leave it in.

This is inference from a product deprecation, not measured data. It depends entirely on how many Gmailified users there were, and Google has never published that number. And it could be a rounding error. It also could be a visible bump in your GANGA segment through 2027.

I’ve diarised a retest for early 2027 and I’ll update this page either way. If I turn out to be wrong, saying so here is worth more than having been right.

What this means for your testing

Four checks. Not forty.

Gmail web, on a Google account
The Gmail app on a Google account
The Gmail app on a non-Google address
Your own email after you’ve forced it to clip

That third one is the check everybody skips. Add a free Outlook.com address to the Gmail app on your phone. Five minutes, once, and it catches the GANGA failures forever.

The sanitizer: why your CSS disappeared

This is the heaviest section, because it’s the largest bucket of Gmail rendering issues by a distance.

What Gmail does to your HTML on the way in

Gmail doesn’t render your email. It rewrites it, then renders the rewrite. Most Gmail rendering issues trace back to that one design decision.

The pipeline, in plain terms:

Your HTML gets parsed and normalised
Class and ID names get renamed, prefixed with m_ and a message ID
Properties that aren’t on Gmail’s allowlist get dropped
External stylesheets are removed outright, no negotiation
Embedded <style> blocks survive only in the head, and only if Gmail approves of everything inside them

Google publishes a supported-property list in its developer documentation. It’s useful, and it describes the happy path. It says almost nothing about the failure modes.

The failure modes are what this section is for.

The all-or-nothing problem

Here’s what catches experienced developers, repeatedly.

Gmail’s handling of a <style> block is not property by property. It’s the whole block or nothing. One rule it dislikes takes everything else with it.

Nested @ declarations

Symptom: all your embedded styles vanish, in every Gmail, at once. Cause: an @ declaration inside another @ declaration. An @font-face or an @import inside a media query is the classic. Usually arrives with a web font. Fix: move anything nested into its own separate <style> block, below the safe one. Effort: quick.

A `url()` in the block, which needs a caveat

Symptom: same total disappearance, and it makes no sense until you know the history. Cause: background-image: url(...) or background: url(...) inside the block. When this fires it can also wipe an entire inline style attribute, not just that one declaration. Fix: keep url() out of embedded CSS. Use the HTML background attribute on the td. Effort: moderate, then permanent.

Now the caveat, because this is the one piece of Gmail advice I see repeated most often with the important half missing.

In July 2023, Gmail web started stripping CSS that contained background image URLs, and it did it to a subset of accounts, which is why half the industry saw it and half didn’t. Mark Robbins filed it on Google’s issue tracker, it collected 300-odd votes, Google acknowledged it, and the rollback finished in early August 2023. So this is not a permanent, documented Gmail behaviour the way the nested @ problem is. It was a bug, and it got fixed.

Why am I still telling you to avoid url() in a style block? Because it broke once, sporadically, without warning, and the HTML background attribute costs you nothing to use instead. That’s a cheap insurance premium. But I’d rather you know it’s insurance than think you’re patching an active fault, because a lot of guides written in that three-week window still read as though the sky is currently falling.

The 8192 character ceiling

Symptom: the first few style blocks work, then everything after a certain point is dead. Cause: Gmail drops the block that pushes cumulative style content past 8192 characters. It then drops every block after it. The count is across all your blocks. Fix: budget your CSS. Put the Gmail-critical styles in the first block. Builder-generated CSS hits this far more often than hand-written CSS. Effort: moderate the first time.

Worth noting that this ceiling has been reported higher at times. Rémi Parmentier’s testing put it nearer 16,384 bytes, on the back of a figure Eric Lepetit shared in the emailgeeks Slack, and it may well have moved again since without anyone announcing it. Treat 8192 as the number you design against anyway. Being comfortably under a limit that turns out to be generous costs you precisely nothing.

A stray typo

Symptom: styles gone, and you swear nothing changed. Cause: one malformed declaration. A missing semicolon. A stray brace. Fix: validate the CSS. Then validate it again after your ESP has been near it. Effort: quick, once you stop assuming it’s Gmail’s fault.

This one is legitimately irritating. Every browser on earth skips a broken rule and carries on. Gmail throws out the whole thing.

What never survives, whatever you do

Short reference list. Don’t fight these, work around them.

External stylesheets
CSS grid, and most flexbox sub-properties
transform, animation, transition
box-shadow, filter, clip-path
position beyond static and relative
Negative margins
Web fonts, beyond Gmail’s own defaults
Attribute selectors and most pseudo-classes

For anything not on that list, check caniemail.com rather than trusting a blog post, mine very much included. That site is maintained properly. I’m not going to reproduce a support matrix here and let it rot.

The rules that actually hold up

Five of them. They’ve survived every Gmail change I’ve had to react to.

Inline everything the email cannot survive without. The embedded block is an enhancement layer, not the foundation.
Split your CSS across multiple <style> blocks. Gmail-safe rules first. Anything exotic isolated in its own block, at the end. If Gmail kills one, the others live.
Keep url() out of embedded CSS. HTML background attribute on the cell, solid background-color behind it as the fallback that never fails.
Test the block is alive, not just that the email looks right. In Gmail web, open DevTools and look for a <style> element inside the message container, or click one of your styled elements and check whether your class-based rule actually appears in the Styles pane. Do not use the m_ prefix on the class attribute as your test – Gmail prefixes those class names in the body markup whether or not your style block survived, so a prefixed class proves nothing. I got that wrong for longer than I’d like to admit, and spent an afternoon convinced a dead block was fine.
If losing the whole style block would destroy the email, the email is built wrong. That’s the test. It’s a harsh one and I stand by it.

Effort: moderate to set up in a template, then quick forever. You’re fixing the template, not the campaign. Do it once.

The auto-linking annoyance

Small one, but it comes up.

Gmail turns bare email addresses, URLs and phone numbers into blue underlined links. Whether you asked or not. Fine, until it lands in the middle of a footer you spent time colouring.

The workaround is a soft hyphen entity, , inserted into the string so Gmail’s pattern matching doesn’t fire. Invisible to the reader, breaks the auto-linking.

It’s a hack. It works. Moving on.

Clipping: when Gmail cuts your email in half

The second big family of Gmail rendering issues isn’t about CSS at all. It’s about weight.

The limits, and why they move

Gmail clips a message when the raw HTML gets past roughly 102 KB on desktop. You get the “[Message clipped] View entire message” link, and the rest hides behind it.

Mobile is tighter and less predictable. Klaviyo’s documentation puts other mobile clients around 75 KB. Email on Acid’s testing found the Gmail iOS app clipping at roughly 20 KB, applied inconsistently. Same email, clipped on one day of testing and not another.

Images don’t count towards the limit, because they load externally. Everything else does.

Your markup
Your inline styles
Your head
Every tracking URL
Every link your ESP rewrites at send time

The clipping point is a byte count, not a sensible content boundary. So it can cut mid-tag, which is how you end up with broken HTML on top of a truncated message.

The two consequences nobody checks

One: the “View entire message” version has <style> tags stripped. Documented by Klaviyo, and it explains a huge share of confused support tickets. A clipped email doesn’t just get shorter. It loses its embedded CSS at the same moment. That’s why the full version so often looks like a different, uglier email built by someone else.

Two: the tracking pixel usually sits at the bottom. So it gets clipped, and the open never registers. Your reporting then lies to you in a direction that looks exactly like a deliverability problem.

Move the pixel up. Put the unsubscribe link somewhere it survives too, because a clipped unsubscribe is a compliance problem, not a design one.

How to measure it properly

Not “does it feel long”. Measure it.

Send a real campaign to yourself from inside your ESP. Open it in Gmail. If it’s clipped, click “View entire message”, then view the page source and check the actual size.

That number is the only one that counts. The export from your builder is not that number.

Aim for 80 KB. Your ESP will add 20 to 30 KB you never wrote – tracking pixels, redirect URLs, injected footers. A 98 KB export can land as a 127 KB send. I’ve watched that gap surprise people who thought they had headroom.

Getting the weight down, in order of return

Strip builder bloat. Drag-and-drop editors produce a startling amount of redundant markup. This is almost always the single biggest win.
Deduplicate repeated inline styles. Same wrapper, written forty times.
Minify – with an email-aware minifier, so MSO conditional comments survive. A general-purpose one will happily destroy them.
Encode special characters as HTML entities. Non-ASCII characters can push size up more than you’d expect.
Cut links. Every URL costs bytes, and redirect URLs cost more than the ones you wrote.
Accept the email is too long. Send a teaser with one hook and one CTA, link out to the rest.

Effort: moderate once, quick forever. Same as the CSS work. You’re fixing the template.

Images that don’t show up in Gmail

Image failures are the third big family of Gmail rendering issues. Top-five support query, and barely anyone writes about the proxy that causes half of it.

The image proxy, and the cache that’s lying to you

Gmail serves every image through Google’s proxy, on googleusercontent domains. Your server is not talking to your subscriber. Google’s cache is.

That cache is aggressive. Here’s the sequence that costs people an afternoon:

You spot a typo in a hero image. You fix it, upload it over the same filename, resend the test. The old image comes back. You start doubting your own eyes.

Fix: cache-bust with a query string while testing. hero.png?v=4. Bump the number every time.

There’s a corporate variant too. Workspace admins can allowlist internal image URLs. Occasionally that’s the answer when B2B recipients see broken images and nobody else does.

SVG is not an option

Gmail’s proxy has historically blocked SVG outright. Use PNG.

One oddity, and it tells you something about how the plumbing works: Email on Acid found that GANGA accounts can render SVG, which suggests those accounts aren’t going through Google’s image proxy at all. Interesting, useless. Still use PNG.

This costs somebody an afternoon roughly once per career, usually after a designer hands over a beautiful, tiny, scalable logo file.

Blocked images and alt text

Some recipients still block images by default. If your email is mostly images, what arrives is a stack of empty rectangles.

Style your alt text. Give it a font family, a size, a colour, a weight. It costs nothing and takes two minutes.

An email opened with images off should still say something useful. That’s a low bar and a lot of campaigns miss it.

Background images, and the GANGA dead end

For most of Gmail, the HTML background attribute on the td is the safest route. It sidesteps the embedded-CSS question entirely, and it works on body, table, td and th.

GANGA is a different story, and I want to be straight about it rather than sell you a workaround that doesn’t work. Email on Acid’s testing found that GANGA accounts don’t support background images through the HTML background attribute or through CSS background styles. Not one or the other. Neither.

So there is no clever fix here. There’s belt and braces for the rest of Gmail – attribute on the outer cell, inline shorthand on the inner, which covers you across the Google-account environments – and then there’s GANGA, where your subscriber gets whatever background-color you remembered to set.

Which makes the fallback colour the actual design decision, not the afterthought.

And then the real question: is the background image worth it at all? A solid brand colour behind white text is a perfectly respectable fallback. It never breaks, in any environment, ever.

Effort: expensive. Retire when: it costs you a deadline. That’s usually the first time.

Responsive and mobile layout in Gmail

Media queries work, except where they don’t

Gmail supports media queries in the web client and in the app on Google accounts. GANGA does not support them at all.

But here’s the cause of most responsive Gmail rendering issues, and it isn’t the media query.

A media query inside a <style> block that Gmail decided to drop is a media query that does not exist. The query is fine. The block died. You’re debugging the wrong file.

So before you rewrite your breakpoints, go back to the sanitizer section and check whether the block survived.

Build so the media query is a bonus

Percentage widths. max-width on the container. Single column wherever the design allows it.

If the layout only works when the query fires, the layout doesn’t work.

The full hybrid approach – fluid base, conditional widths for Outlook, queries layered on top – is covered properly in the pillar. No point repeating it here at length.

The small stuff that breaks on phones

Minimum 44 by 44 for anything tappable. Apple’s guidance says points rather than pixels, which everyone in email treats as pixels and gets away with, but that’s the reason the number looks oddly specific.
Body copy at 16 pixels. Below roughly 13 pixels, iOS may rescale your text and wreck the layout you tested.
Add -webkit-text-size-adjust: 100% to the body to stop that happening.
Bulletproof buttons as padded table cells with a background colour. Never as an image of a button.

An image of a button, in an environment where images are blocked, is a blank space where your CTA used to be.

Dark mode in Gmail

Dark mode is where Gmail rendering issues get quiet. Nothing collapses. The logo just grows a white box, and the subscriber deletes the email without mentioning it.

Three Gmails, three behaviours

Gmail web mostly leaves the message body alone and darkens the interface around it. Which sounds harmless and isn’t. A glaring white email sitting in a dark window looks like a mistake.

The mobile apps are more aggressive. Gmail on iOS is the highest-risk surface, particularly for sections you already designed dark. Those can get inverted into something pale and wrong.

Android sits somewhere in between, and varies by app version. Which is a polite way of saying test it.

Don’t rely on prefers-color-scheme in Gmail

I’ll state this plainly, because plenty of guides imply otherwise.

Apple Mail and the modern Outlooks respect prefers-color-scheme. You get real control there. Gmail’s handling is unreliable and varies by platform.

So Gmail is a resilience problem, not a theming problem. Design something that survives being inverted, rather than something that assumes it won’t be.

Fixes that hold

<meta name="color-scheme" content="light dark">
<meta name="supported-color-schemes" content="light dark">

Both in the head. They help in the clients that listen, and cost nothing in the ones that don’t.

Then:

Transparent PNG logos, with a thin outline stroke so the mark stays visible either way
Avoid pure #FFFFFF and pure #000000. Near-white and near-black invert far more gracefully.
Check contrast in both modes, not just the one you designed in
Never put dark text on a background that might invert underneath it

Effort: moderate to set up in a template, quick per campaign afterwards.

One opinion, freely given. The glow-behind-the-logo trick works and looks like a mistake somebody tried to cover up. A properly prepared transparent PNG looks intentional. Designers can tell the difference, and so can subscribers.

Gmail rendering issues that aren’t Gmail at all

A decent slice of reported Gmail rendering issues turn out to be something else entirely. The email is broken, the diagnosis is wrong.

Your ESP is a rendering step

GetCourse, Mailchimp, Braze, HubSpot, Salesforce Marketing Cloud. All of them do versions of the same thing.

They rewrite links for tracking. They inject pixels. Some reformat markup they don’t recognise, which is how conditional comments get eaten and style blocks get mangled.

The rule: paste the raw HTML, save, then test again from inside the platform. On a real send. Not from your local file.

If an email passed every check and still broke, this is where I look first. Testing the version you wrote, rather than the version that gets sent, tests the wrong thing.

Forwarding is not testing

Forward an email to yourself in Gmail and it will fall apart.

Gmail rebuilds the HTML on forward. Wrapper markup gets added, styles get mauled, the layout shifts. Then people report a bug that only exists in the forwarded copy.

Use your ESP’s test send. Always. I’ve seen more imaginary bugs diagnosed this way than real ones.

Threading and repeat test sends

Send five tests with the same subject line and Gmail threads them. A threaded view can clip for that reason alone, before your email is anywhere near the size limit.

Vary the subject on every test send. Add a timestamp. Takes a second.

The device, not the client

Sometimes it’s neither your code nor Gmail’s rendering. A specific Android build or app version mangles things, and nothing else does.

The diagnostic tell is scope. If it’s one device, one OS version, one app build, and every other environment is clean, it’s a client bug. Report it, work around it, and don’t rebuild a template over it.

The AI layer is now part of how your email renders

On 8 January 2026, Google announced that Gmail was entering what it calls the Gemini era, on the back of Gemini 3. The headline feature for our purposes is AI Overviews: Gmail synthesising a long thread into a summary, and answering questions about your inbox in natural language. Thread summaries went out to everyone at no cost. Asking your inbox questions sits behind Google AI Pro and Ultra. There’s also a new AI Inbox, which filters the clutter and surfaces to-dos, and that one went to trusted testers first.

Two things worth getting right, because a lot of write-ups have blurred them together.

It started small. The rollout began in the US, in English, and Google said more languages and regions would follow. So depending on your list, this may not have touched your subscribers yet.

The Promotions tab relevance sort is a separate, earlier change. Google announced sort-by-most-relevant for Promotions back in September 2025, alongside the Purchases view. Users can still switch back to most recent. Whether that toggle survives is anybody’s guess, and I’d bet against it, but right now it exists.

Either way, the direction is the same. A machine reads your email before your subscriber does, and it produces the first thing they actually see.

That makes it a rendering concern, even though it looks nothing like the Gmail rendering issues in the rest of this guide.

Summaries are generated from body text

This is the part that matters technically.

Summaries are built from the text content of the email. Alt text is not used. Text baked into an image is not used.

The hard evidence for that comes from the Apple side, and I’d rather cite it properly than pretend otherwise. Knak ran a set of five versions of the same email through Apple Intelligence – image-only with no text, image-only with alt text, image-only with alt text and a preheader, mixed, and fully live text – and found the alt text wasn’t picked up at all. Twilio’s testing landed in the same place independently. Nobody has published an equivalent teardown for Gemini in Gmail that I’d stake anything on.

So: proven for Apple Mail, strongly assumed for Gmail. Design for both the same way, because the fix is identical and it’s free.

So the image-only email doesn’t just fail accessibility and blocked-image opens. It now produces a vague or actively misleading summary, which is worse than a plain text email would have been.

Your beautifully typeset hero headline may as well not exist. The summariser cannot read it.

What to do about it

Put the core message in real HTML text, near the top. Once, clearly, in one sentence.
Keep writing preheaders. They still feed the summary as input, and they still display in clients that don’t summarise.
Front-load the offer, the deadline, the benefit. If it’s buried in paragraph three, it may not surface at all.
Stop treating the first 100 words as warm-up.

Annotations and deal cards

Promotions tab annotations still exist. Schema.org markup, Promotions tab only, mostly mobile, and they need sender registration with Google.

They’re also subject to quality filters, which means correct markup may simply not render. Set expectations accordingly rather than selling it internally as a growth hack.

Gmail’s AI now extracts deal information without your markup anyway. Which somewhat reduces the incentive.

My read on all of it

This is not the death of email design. It’s a second rendering surface with different rules.

Semantic structure and live text are now rendering concerns. That’s a strange thing to type after years of nested tables and conditional comments, and I’m still adjusting to it.

How to test for Gmail rendering issues without a $500 subscription

The Gmail testing order

Do them in order. The early steps are free and catch most Gmail rendering issues before you’ve spent anything.

Browser first. Open the HTML in Chrome. Catches structural errors and broken paths in about thirty seconds.
Real send from inside your ESP to a real Gmail address. Not a forward.
Same send, Gmail app, Google account.
Same send, Gmail app, non-Google address. This is the GANGA check. It’s the one everybody skips, and it catches the failures nobody else finds.
Size check on the real sent HTML, after the platform has done its rewriting.
Dark mode pass. Gmail on iOS first, it fails hardest.
The unglamorous list. Every link, alt text on every image, plain text version, unsubscribe.

Steps one to four cost nothing but a free Outlook.com address and a phone.

Tools and prices, checked recently

Pricing in this category has moved a lot, so I re-checked before publishing.

Tool	Price	What you get	Who it’s for
Litmus Core	$500/month	5 users, 2,000 previews/month, 100+ clients, QA checks, analytics	Agencies and in-house teams sending constantly
Mailgun Inspect Basic	$99/month	Unlimited users, 1,000 previews/month, $0.15 per overage	Freelancers and small teams who need real coverage
Mailgun Inspect Premium	$199/month	2,000 previews, accessibility tests, code and link analysis	Teams that want QA automation too
Mailtrap	Free tier, paid from around $17/month	SMTP sandbox, HTML analysis, pipeline testing	Developers testing in staging
Mailosaur	Personal from $20/month, billed annually	Automated inbox testing via API	Anyone testing email inside CI
Your own devices	Free	One phone, one laptop, three accounts	Everybody, always, first

On Litmus. In August 2025 the $199/month Plus plan became Core at $500/month. Same feature set, 151% more money. The $99 Basic tier was removed entirely. Validity acquired Litmus in April 2025 and the pricing moved a few months later. Draw your own conclusions.

Do the preview arithmetic before committing. Each individual client screenshot burns one preview. Test one email across six Outlook versions and three Apple Mail versions, desktop and mobile. That’s around 18 previews per test. Two thousand a month sounds generous until you’re iterating.

On Email on Acid. Most articles haven’t caught up with this one. Email on Acid is becoming Mailgun Inspect. Subscription customers began transitioning in June 2026, and annual plans migrate at the end of their term.

The old unlimited previews pitch is gone. Basic is $99 with 1,000 previews and a $0.15 overage, Premium is $199 with 2,000. You do get unlimited users on both, which is a fair trade if you’re a team and a downgrade if you’re one person who tested a lot.

Two things in the migration notes that will catch people out. Your existing previews and tests don’t come across, so archive anything you need. And the analytics side is gone entirely – Inspect is pre-send QA only. If you were using Email on Acid’s tracking pixel for post-send data, that’s not coming with you.

Still better value than Litmus for most people. But check your plan if you picked it specifically for unlimited testing.

On Putsmail. Retired. Gone. A lot of older tutorials still link to it, so better you hear it here than after ten minutes of clicking.

My honest recommendation, tiered

One email a month, small business: your own devices plus a free tier. You do not need a $500 subscription. You need a phone, a laptop and twenty minutes.
Weekly sends, one person: Mailgun Inspect Basic. The preview cap is comfortable at that volume.
Agency or a real in-house programme: Litmus is still the most complete platform, and at agency volume the cost per email is defensible.

For Gmail specifically, honestly? A free Google account plus a free non-Google address in the Gmail app covers most of what breaks. The paid tools earn their money on the clients you can’t reach, and for Gmail that list is short.

I’d rather say that in the section with the affiliate links in it. A recommendation only means something if it can go the other way.

The Gmail pre-send checklist

Twelve items. Screenshot it, print it, stick it somewhere.

Rendered in a browser, no structural errors
Real send from inside the ESP, not a forward
Opened in Gmail web
Opened in the Gmail app on a Google account
Opened in the Gmail app on a non-Google address
Style block confirmed alive – your class-based rule visible in the DevTools Styles pane, not just a prefixed class attribute
No url() anywhere in embedded CSS
HTML size measured after ESP processing, under 80 KB
Tracking pixel and unsubscribe positioned above any clipping point
Dark mode checked, Gmail iOS first
Every image has styled alt text, and a PNG rather than an SVG
Core message present as real HTML text near the top, not baked into the hero

(Printable version at the end of this post, if you want it.)

What changes in Gmail next

Predictions, with confidence levels attached. I’d rather be specific and occasionally wrong than vague and unfalsifiable.

High confidence: the sanitizer stays. It’s a security boundary, not a feature backlog item. Google has no reason to loosen it, and every reason not to. Anyone waiting for Gmail to start supporting grid is going to be waiting a long time.

High confidence: the AI layer gets more prominent, not less. Summary quality becomes something senders are judged on, whether they signed up for it or not. The AI Inbox view widens. Relevance sorting spreads.

Medium confidence: GANGA’s share rises through 2027, then flattens. Gmailify winds down, plain IMAP picks up those users, and inline-first stays the correct default for longer than anyone expected in 2024. This is the prediction I’m least sure of, and I’ve said why above.

Medium confidence: clipping limits do not get raised. They haven’t moved meaningfully in years. There’s no commercial pressure on Google to move them, and a decent argument for keeping the inbox light.

Low confidence, but watching: interactive email stays niche. AMP for email launched in Gmail in 2019 and still runs in Gmail, Yahoo Mail and Mail.ru, plus FairEmail if we’re being thorough, which nobody’s audience is using. Per-sender registration, mandatory HTML fallback. Seven years, three clients that matter. Not a strategy.

The constant: Gmail changes without telling anyone. Usually to a subset of accounts first. New Gmail rendering issues tend to arrive quietly, in one environment, on a Tuesday. Retest quarterly whether or not anything appears to be wrong.

FAQ about Gmail rendering issues

Why does my email look different in Gmail than in other email clients?

Because Gmail rewrites your HTML before rendering it. It renames classes, drops properties that aren’t on its allowlist, removes external stylesheets, and discards <style> blocks it dislikes. Apple Mail renders close to a browser. Classic Outlook uses an entirely different engine. Same HTML, three very different interpretations.

Why does Gmail strip my CSS?

Because its sanitizer handles embedded styles as a whole block, not rule by rule. This causes more Gmail rendering issues than anything else. One thing it objects to removes everything. The reliable triggers are nested @ declarations, cumulative style content over 8192 characters, and plain typos. A url() in the block did this too during a 2023 bug that Google rolled back, and it’s still worth avoiding. Split your CSS across multiple blocks so one failure can’t take the rest.

What is the maximum email size before Gmail clips it?

Around 102 KB of raw HTML on desktop. Other mobile clients sit near 75 KB, and the Gmail iOS app can clip at roughly 20 KB, applied inconsistently. Images don’t count, but the markup and URLs that display them do. Aim for 80 KB, because your ESP adds 20 to 30 KB in tracking and rewritten links.

Why does my email look fine in Gmail on desktop but broken in the Gmail app?

Most likely the account type. The Gmail app connected to a non-Google address over IMAP is GANGA, and it doesn’t support embedded <style> at all. No media queries either. Everything critical has to be inline. The iOS app also clips at a much lower size threshold than desktop.

Why are my images not showing in Gmail?

Three usual causes. The recipient has images blocked, in which case style your alt text. The file is an SVG, which Gmail’s image proxy has historically blocked, so use PNG. Or you’re seeing a cached version through Google’s proxy after replacing the file – add a query string to cache-bust during testing.

Do media queries work in Gmail?

Partially. They work in Gmail web and in the app on Google accounts. They don’t work in GANGA. And a media query inside a <style> block that Gmail dropped won’t fire either, which is the most common cause of unresponsive emails in Gmail. Build a fluid base layout that works without them.

Can I use background images in Gmail emails?

Yes, in most of Gmail. Use the HTML background attribute on the table cell, and add the inline CSS shorthand as a second layer. Keep url() out of embedded <style> blocks as a precaution. GANGA supports background images through neither method, so a solid background-color fallback isn’t optional there, it’s the whole design.

Why did my email break after I forwarded it to myself in Gmail?

Because Gmail rebuilds the HTML when you forward a message. Wrapper markup gets added and styles get mangled, so the forwarded copy is not the email you sent. Forwarding is not a test. Send a real campaign from inside your ESP to a real address instead.

My Gmail inbox layout looks wrong – is that the same problem?

No, that’s a different thing entirely. Missing tabs, a reading pane in the wrong place, or Smart Features switched off are Gmail interface settings, not email code problems. Check your Gmail display settings, or Google’s own help pages. Nothing on this page will fix that, and I’d rather say so.

Where I’d start tomorrow

Find out whether Gmail stripped it or cut it. Then find out which Gmail. Two questions handle the large majority of Gmail rendering issues, and the code usually tells you the rest.

When somebody sends me a broken Gmail screenshot, I don’t open the HTML first. I ask three things. Is there a “View entire message” link? Is it a Google account or an IMAP address in the app? Web, or the app?

Most of the time that narrows it before I’ve read a line of code.

Keep a note of which workarounds you’re maintaining and why. Nobody does this, and it’s how you eventually know when to stop maintaining them.

Got something misbehaving in one specific Gmail and can’t work out why? Send the HTML and a screenshot. That’s the kind of puzzle I like.