How image refresh works

Swind lets you update images in emails that have already been sent. This page explains the mechanics, how re-fetching works, why token usage can be higher than your open count, and how the Refresh Window lets you control the trade-off.

What is a fetch?

A “fetch” is when your email client (Gmail, Outlook, Apple Mail…) downloads an image from a URL. Unlike attachments, images in emails aren't stored inside the email itself, they live on a server and are downloaded fresh each time someone opens the email.

This is what makes Swind work: because images are fetched from our server on demand, uploading a replacement means anyone who opens the email next gets the new version, even if the email was sent days ago.

Opening an email

When someone opens an email, their email client reads the HTML and downloads every image separately from the source URL. The image tags in your Swind-powered emails look like this:

That URL doesn't point to a static file on a CDN. It points to Swind's server, which serves the current version of your image on demand. Every time the email client requests that URL, Swind decides what to return based on what you last uploaded.

What happens when an email is opened

Why images re-fetch constantly

Email clients don't cache images the way browsers cache web pages. Gmail, in particular, re-fetches images periodically, roughly every 60 seconds, while the email is open. This behavior was designed to support live content like countdown timers, weather widgets, and stock tickers.

This is a feature, not a bug. It's exactly what makes Swind's image swap possible: because Gmail re-fetches, the next request after you upload a new image will return the new version. The downside is that re-fetches can also consume tokens.

Re-fetch behavior while an email tab stays open

How Swind uses this

When you upload a replacement image in Swind, the file on our server is updated. The HTML in your email stays exactly the same, the image URL doesn't change. But the next time Gmail re-fetches that URL, it gets the new image.

This means swaps are fully retroactive. An email sent to 50,000 people six days ago will show the new image to anyone who opens it today, as long as the Refresh Window is still open.

The swap window matters

Image swaps only reach recipients while the Refresh Window is open. Once the window closes, email clients receive a long-term cache instruction and stop re-fetching. Swaps uploaded after that point won't be seen by anyone who already cached the old image.

What are tokens?

In Swind, a tokenis used every time one of your image sections (slices) is served. Each open of an email uses 1 token per slice it contains: a 5-slice email uses 5 tokens per open. It's a transparent measure of what our servers actually deliver. Several things can consume tokens beyond a simple human open:

·They open the email at 9 am and leave the tab open all day → re-fetch sessions keep the counter moving
·They open it once on desktop, once on mobile → at least 2 separate open sessions
·Gmail's proxy pre-fetches the images before the email is fully rendered → tokens before the recipient even reads it
·Anti-spam scanners and corporate email gateways fetch images as part of security checks

Swind tokens ≠ email opens. Tokens are closer to "image impressions", they measure how many image sections were delivered, not how many people read your email. Traditional email platforms count opens differently (usually via a 1×1 tracking pixel loaded once).

Why token counts inflate

The biggest source of extra tokens is automated traffic, requests that come from systems rather than humans reading your email. Here's what's happening behind the scenes:

Sources of inflated views for a single recipient

Gmail tab left open on desktop (per hour)

more tokens / hr

Gmail mobile, separate device

+ tokens

Google image proxy pre-fetch

+ tokens

Anti-spam / security scanner

+ tokens

Total recorded for 1 person, 1 email open (left in tab)

60+ views / hr

Gmail's image proxy

Google routes image requests through their own proxy servers. Gmail desktop usually serves a cached version, but Gmail mobile on some devices re-fetches more aggressively, and the requests come from rotating IP addresses, which makes it impossible to deduplicate them by IP.

Anti-spam scanners

Security tools pre-fetch images to check for malicious content before delivering the email. These scans happen before the recipient opens anything, and the scanner's user-agent string is often indistinguishable from a real browser.

Persistent tabs

A single email left open in a browser tab generates a re-fetch every ~60 seconds as long as the tab is active. Someone who leaves Gmail open overnight on a laptop can accumulate far more tokens than a single quick read would suggest.

The Refresh Window

The Refresh Window is the mechanism that lets you control the trade-off between image swap flexibility and token usage.

While the window is open, Swind tells email clients to re-fetch images every 60 seconds by responding with Cache-Control: max-age=60. Once the window closes, Swind switches to a one-year cache: max-age=31536000, immutable. Email clients that request the image after that point store it locally and stop re-fetching indefinitely.

Cache-Control changes over the lifetime of a campaign email

What closing the window means

✓Tokens stop accumulating from re-fetches
✓Automated noise (bots, scanners, proxies) no longer consumes tokens
✗Image swaps are no longer visible to recipients who already cached the image
✗Recipients opening the email for the first time after closing will re-fetch once, then cache

Campaigns vs Flows

Campaigns and flows have different lifecycles, and the Refresh Window strategy should reflect that.

📣 Campaigns

Sent once to your entire list. Nearly everyone receives it within the same few hours. If you need to fix a typo or swap an image, the correction window is short, typically under 24 hours before most of your audience has already seen it.

⚙️ Flows (automations)

Triggered individually as subscribers join or take action. The same welcome email may be sent today, next week, and next month. Images need to stay updatable over a much longer horizon, a new subscriber in 3 months should see your current branding.

For campaigns, a short window (24 h) limits re-fetch noise while still covering most corrections. For flows, you choose how often email clients re-fetch, daily is the sweet spot for most teams.

Our recommendation

Campaigns: 24 hours

Default

Covers the vast majority of corrections, most teams fix any issues within the first 24 hours of a send. After that, view counts stabilize and the cached image is served with a 1-year header, so recipients who already downloaded it won't trigger further re-fetches.

Flows: Once a day

Default

Re-fetches at most once per 24-hour period per recipient. New subscribers always get the most current image, while people who already received the email don't generate view noise more than once a day. Increasing this to every hour makes swaps visible faster but at the cost of more views recorded.

Both settings can be adjusted in Settings → Refresh. Changes take effect on the next re-fetch, no need to re-send anything.