Start with what Gmail actually does
Gmail plays GIF animation everywhere it ships, the web app and both mobile apps, no tap required, and that behavior has been stable for years (still true as of mid-2026). A Gmail-heavy audience means motion is available by default, a courtesy classic desktop Outlook has never extended, since its Word renderer stops at the first frame.
No list is pure Gmail, though, so give the opening frame a job anyway: it should read as a sensible still for whoever is stuck on a frozen client. Costs nothing, saves the stragglers. With playback settled, Gmail's two real quirks deserve the attention: a widely misread clipping rule, and a proxy standing between your server and every open. Both are manageable once you know which budget they draw from.
Roughly 102KB of HTML, and not one image byte
Gmail truncates any message whose body markup exceeds roughly 102KB and hides the remainder behind a View entire message link. The number measures HTML, not images. An 800KB GIF spends nothing against it; three thousand lines of nested-table template spend all of it.
Read that as an argument for the GIF. A single loop can do the work of a screenshot pile and its explainer rows, which shrinks the markup, which buys distance from the clip. Anything below the cut is functionally invisible, and on a bad day that includes the unsubscribe link, a deliverability problem wearing a UX costume.
- Spend markup like it's metered. It is, at roughly 102KB.
- Front-load the ask. A call to action below the clip might as well be in a different email.
- Proof in a real Gmail inbox. The clip only reveals itself on delivery, never in your ESP's preview.
Every image arrives via Google's proxy
Gmail rewrites image URLs and serves them from Google's cache rather than your host. The good news: the proxy passes animation through intact, so the loop plays exactly as exported, and images display by default for most accounts. The catch is permanence. Once Google caches your GIF, swapping the file on your server afterward is unreliable. Whatever you sent is what exists.
And keep writing alt text. Some corporate Gmail configurations still block remote images, and one plain sentence beats an empty gray box for every reader whose images are blocked.
Weigh the file against a phone, not a spec sheet
Gmail publishes no GIF ceiling, so the real limit is the reader's connection: plenty of opens happen on mobile data. Stay at roughly 1MB or below, lighter when the loop allows, at the roughly 600 to 640 pixel width most templates render. Lean sends keep total message weight down too, which is never wasted effort where deliverability is concerned.
Order of operations matters. Duration first (a 2 to 4 second loop), then frame rate (10 to 15 fps is plenty for inbox motion), then palette (64 or 128 colors, with dithering hiding the seams in gradients). The output estimate refreshes after each change, so you can quit the moment the number behaves. If the file stays stubborn, the small-GIF playbook continues where this page stops.
Make it without handing the footage to anyone
Drop the video into What the GIF: mp4, mov, webm, or any format your browser already plays. Processing is local to your machine, so there's no uploader, no queue, and no copy of your clip sitting on a server. Each arrow-key tap advances the edit by exactly one frame, so the loop seam lands precisely where the motion resets.
If the loop needs words, bake in up to three captions, classic meme lettering or a neater face in any color you pick, each with optional timing so a line can wait its turn. If it needs structure, up to ten clips can run in sequence with hard cuts between them. Then insert the export in Gmail's composer or your ESP like any image, and pick a cut that's still likable on the tenth pass, because Gmail will happily deliver all ten.