Do countdown timers work in Outlook?

The short answer: yes, with one caveat you should design around. A countdown timer in email is an image, and every version of Outlook displays images once the recipient allows them. The caveat is animation: older perpetual Outlook for Windows releases — and any classic Outlook install where animated graphics are turned off — show the first frame of an animated GIF and stop. Current Microsoft 365 classic Outlook can animate GIFs when the relevant setting is on, but you cannot know which build or setting a recipient has. So the design question is: what happens when only the first frame shows? If the image is rendered at the moment it is requested, that first frame is a correct countdown — just a still one.

The rest of this post unpacks that answer, because the details matter.

A countdown timer in email is just an image

Ordinary HTML email cannot reliably execute sender-supplied JavaScript, so a countdown cannot be computed in the client the way it is on a web page. Production email countdown timers therefore work the same way: an <img> tag whose src points at a server. When the client fetches the image, the server computes the time remaining at that moment and returns an image showing it. The “liveness” comes entirely from the fact that the fetch happens when the email is opened, not when it is sent.

That is how DynaMail’s countdown widget works too: the widget is a plain URL, the file extension requests the output format, and the server renders the frames from the current clock on every uncached request.

<!-- Animated countdown (GIF: the safe animated format) -->
<img src="https://img.dynamail.io/widgets/YOUR-WIDGET-ID/render.gif" alt="Sale ends soon" />

<!-- Static snapshot of the same countdown (PNG) -->
<img src="https://img.dynamail.io/widgets/YOUR-WIDGET-ID/render.png" alt="Sale ends soon" />

What classic Outlook does with animated GIFs

Classic Outlook for Windows renders HTML email with Microsoft Word’s rendering engine. In older perpetual releases that engine shows only the first frame of an animated GIF — and even in current Microsoft 365 classic Outlook, animation plays only when the show-animated- graphics setting is on; when it is off, recipients get the first frame and nothing else. This is the single most common reason people believe countdown timers “don’t work in Outlook.”

The rest of the Outlook family — Outlook on the web, Outlook for Mac, and the newer Windows client — generally animates GIFs normally. You cannot control which variant your recipients use, and most real-world lists contain a mix, so the practical question is not “does Outlook animate?” but “what does my timer look like when it doesn’t?”

Why the frozen first frame is still correct

Here is the part most articles skip. If your countdown GIF was rendered once — say, when you built the campaign — its first frame shows the time remaining as of that moment. Everyone whose client freezes on the first frame sees a number that was right on Tuesday. That is a broken timer.

If instead the frame set is computed at request time, the math changes. When Outlook (or the proxy in front of it) fetches the image, the server computes the time remaining right then and encodes the frames starting from that moment. The first frame is an accurate snapshot of the countdown as of that fetch. A first-frame-only client freezes it — but it freezes a correct number. A reader who opens the same email tomorrow usually triggers a new fetch and a new, again-correct snapshot; when an intermediary serves its own cached copy instead, the snapshot is as fresh as that cache allows.

One honest qualifier: no per-open rendering is literally uncached. DynaMail caches animated countdown renders for about one second, so “accurate to the second at the moment of fetch” is the precise claim — and intermediaries like Gmail’s image proxy or Apple’s privacy proxies can serve their own cached copy (more on that in our Apple Mail Privacy Protection post).

If you’d rather not animate at all: a static snapshot

Sometimes the right answer for an Outlook-heavy audience is to skip animation entirely. In DynaMail, requesting render.png for a countdown is an explicit choice of a static, single-frame snapshot: the server renders the time remaining at the moment of the request as one still image. Nothing ticks, so nothing can look frozen — the design is honest about being a snapshot, and it is a lighter file than a multi-frame GIF.

Countdown renders — including the static PNG snapshot — use the same roughly one-second cache policy, so the still image is as current as the animated one. (Other widget types have their own type-specific policies; non-time-critical static widgets advertise caching of up to a minute.)

Why there is no automatic “Outlook gets a PNG” switch

A reasonable question: why not sniff the user agent and serve classic Outlook a static image automatically? Because in email, you usually are not talking to the reading client at all. Gmail fetches images through its proxy; Apple Mail Privacy Protection fetches through Apple’s proxies; other providers have their own intermediaries and caches. The user agent on the request often identifies the proxy, not the client — and a response cached by a proxy can be re-served to a different client later. Guessing the client and silently switching formats would be wrong often enough to be worse than not trying.

So DynaMail keys the format to the URL extension rather than to any guess about the client: render.gif, render.apng, render.webp, or render.png. You choose, explicitly. (One nuance: for the countdown, render.png is always a static snapshot, but for some other widget types an animated design may be served in a compatible animated format even when a static extension is requested.) The tradeoffs between the four formats get a full post of their own.

Practical recommendations

• Default to an animated GIF. It animates in most clients, and in first-frame-freezing clients a request-time-rendered timer still shows the correct time remaining.
• Make sure the first frame carries the message on its own — with open-time rendering it shows the right numbers, but the design should read clearly as “time remaining” without motion.
• If your audience skews heavily toward classic Outlook for Windows (common for B2B lists), consider shipping the static PNG snapshot instead and let the copy around it create the urgency.
• Do not promise on-screen ticking in your own QA notes — the honest claim is “correct at every open,” not “animating in every client.”
• Send yourself test emails in the clients your audience actually uses. Client behavior is the ground truth; no compatibility article (including this one) substitutes for it.