You replace a campaign image in the file archive, check the website — and it looks fine. But a colleague still sees the old image, and so do some customers. Nothing is broken: this is caching working exactly as designed. This article explains how images are cached in Dynamicweb and in visitors' browsers, why an image replaced under the same name may take days to show up for returning visitors, and how to publish image changes so everyone sees them immediately.
Two different caches are involved
When an image travels from the Dynamicweb file archive to a visitor's screen, it passes through (at least) two caches:
- Dynamicweb's generated image cache — a copy stored on the server, so Dynamicweb doesn't have to resize and convert the same image again for every visitor.
- The browser cache — a copy stored on the visitor's device, so their browser doesn't have to download the same image again on every page view.
These two caches are completely independent. Dynamicweb controls the first one; the visitor's browser controls the second, following instructions it received when it downloaded the image. Understanding the difference is the key to everything in this article:
Dynamicweb may have the correct new image ready on the server, but a returning visitor's browser can still decide to use the copy it already stored locally — without ever asking the server.
Note
If your solution uses a CDN, that adds a third cache layer between the server and the browser. It caches by URL, just like browsers do, so everything in this article about image URLs applies there too.
How Dynamicweb-generated images are cached
Dynamicweb usually doesn't serve images as the file the editor uploaded. Templates request images through the image handler, which generates derived versions of the original — a resized version for a product card, a cropped version for a banner, a WebP version for faster loading, and so on. One uploaded image can easily exist in five or six generated variants.
Generating a variant takes work, so Dynamicweb keeps the generated copy in a cache folder on the server (/Files/Cache.net/Images) and serves the same file quickly the next time that exact variant is requested. (How templates request these variants is covered in Image Handler for implementers.)
What happens when the original changes? Dynamicweb checks, on each request, whether the original file is newer than the generated copy. If you replace an image in the file archive, the old generated variants are considered outdated, and each variant is regenerated the next time someone requests it. You don't need to clear anything manually — the server side takes care of itself.
So far so good: the server always serves an up-to-date image. The waiting-time problem lives in the next cache.
How browser caching works
When a browser downloads an image, the response includes an instruction telling the browser how long it may reuse its local copy without asking the server again. In Dynamicweb this duration is the Cache-control max-age in seconds setting on the Image handler settings page — the default is 604800 seconds, which is 7 days.
The user-facing effect:
- The first time a visitor loads the page, the browser downloads the image and stores a copy.
- On later page views, the browser uses its local copy. While the copy is still considered fresh — within the 7 days — the browser typically doesn't contact the server at all. Not even to ask whether the image changed.
- After the freshness period ends, the browser checks back with the server the next time the image is needed.
This is very good for performance: pages load faster for returning visitors, and far fewer requests reach the server. It also means that during those 7 days, the browser is deliberately not looking for updates.
What the ETag does
Alongside the caching instruction, every image response includes an ETag — think of it as a version label for the file. The browser stores the label together with the cached image.
When the freshness period has ended and the browser needs the image again, it doesn't blindly re-download it. Instead it asks the server: "I have version abc123 — is that still current?"
- If the server answers "yes, still current", the browser keeps using its cached copy, and only a tiny confirmation travels over the network instead of the whole image. The image is then treated as fresh again for another cache period.
- If the server answers "no, here is the new version", the browser downloads the new image and replaces its cached copy.
Two things are important to understand about this check:
- The ETag doesn't help while the cached image is still fresh. The browser only asks the "is my version current?" question after the cache lifetime has passed. Within the 7 days, no question is asked at all.
- Replacing a file does change the version label. For generated images, the label includes when the original file was last changed — so when the browser eventually checks back, a replaced image is detected and the new version is delivered.
The practical conclusion: after replacing an image under the same name, returning visitors catch up when their cached copy expires — with the default settings, up to 7 days after their last visit. If the change must reach everyone immediately, use a new URL — covered below.
What happens when an image is replaced under the same name
Let's make it concrete. A campaign page uses this image:
/Files/Images/campaign/summer-sale.jpg
The cache lifetime is the default 7 days. Here's the timeline:
| When | What happens |
|---|---|
| Monday | A visitor opens the page. Their browser downloads summer-sale.jpg and caches it — fresh for 7 days. |
| Tuesday | The editor uploads a new campaign image with the same name and path, replacing the file. Dynamicweb notices the change and regenerates its server-side variants on the next request. |
| Tuesday onwards | New visitors — anyone who never downloaded the image before — see the new image. |
| Wednesday | The Monday visitor returns. Their browser still considers its cached copy fresh, uses it without contacting the server, and shows the old image. |
| Next Monday or later | The Monday visitor's cache lifetime has passed. The next time they view the page, their browser asks the server whether its version is still current. The version label changed when the file was replaced, so the browser downloads the new image. |
The summary: after a same-name replacement, returning visitors keep seeing the old image until their cached copy expires — up to the full cache lifetime (7 days by default) after they last loaded it. This isn't a malfunction; the browser is doing exactly what it was told: "you may reuse this image without asking."
This is also why the problem is so confusing to reproduce: it looks different per person. The editor who just uploaded the file (and pressed refresh a few times, or has developer tools open with caching disabled) sees the new image. A customer who visited yesterday sees the old one. Both are "right."
Why a new file name works immediately
Browsers cache by URL. The entire caching story above — the local copy, the freshness period, the version label — is attached to the exact image address. That gives you a simple, completely reliable way to publish a new image:
Upload the new image under a new name, and point the page at it.
Instead of replacing:
/Files/Images/campaign/summer-sale.jpg
upload:
/Files/Images/campaign/summer-sale-2026.jpg
and update the page or paragraph to use the new file. The effect on caching:
- Same URL: the browser thinks "I already have this image" — and uses its old copy.
- New URL: the browser thinks "I've never seen this image" — and downloads it. Immediately. For every visitor.
There is no cache anywhere — browser, CDN, or server — holding a copy of a URL that never existed before. That's why versioned file names (summer-sale-2026.jpg, hero-week-32.jpg, logo-v2.svg) are the standard technique for images that must change at a known moment. The old file can stay in the archive untouched; unused files don't cost anything.
Choosing a cache lifetime
The Cache-control max-age in seconds setting is a trade-off dial, and 7 days is a sensible default for most websites:
| Shorter lifetime (e.g. 1 hour – 1 day) | Longer lifetime (e.g. 7–30 days) |
|---|---|
| Same-name replacements reach returning visitors sooner | Same-name replacements can take a long time to reach everyone |
| Browsers check back with the server frequently — more requests, slower repeat visits | Fast repeat visits, far fewer requests to the server |
| Useful where files are often replaced in place | Best for stable images: products, brand assets, content photos |
Reducing the lifetime may make sense for solutions where editors frequently replace files under the same name, for very time-sensitive imagery, or on development/test environments where you're actively swapping files.
It is usually not the right tool for busy production sites: most images (product photos, logos, content images) rarely change, and shortening the lifetime penalizes every image on the site to solve a problem that only affects replaced files. Image loading speed also feeds into page performance metrics, and performance influences user experience and the quality signals search engines derive from it — so give the caching benefit away deliberately, not by default.
A shorter cache lifetime gives you faster updates when reusing the same image URL — but it also means every browser asks Dynamicweb for images more often.
Note that the setting takes effect for a visitor when their browser next contacts the server: copies already cached under the old lifetime keep their original expiry.
Recommendations
- For images that rarely change — products, logos, content photos — keep a long cache lifetime and enjoy the performance.
- For campaign images that must change at a specific time, use a new file name (or a new URL) and update the page to reference it. This is the only approach that reaches every visitor immediately.
- Don't rely on replacing a file under the same name when it matters that all visitors see the new version — returning visitors may see the old image for days.
- Shorten the cache lifetime only where fast in-place updates genuinely matter more than performance — and prefer doing it on test environments rather than production.
- Remember the two caches are different things. Refreshing or clearing anything on the server does not remove copies already stored in visitors' browsers.
- Test like a visitor. Check with a normal browser session — a hard refresh (Ctrl+F5) or developer tools with "disable cache" bypasses exactly the behavior you're trying to observe, which is why "it works on my machine" is so common with caching issues. A private/incognito window behaves like a first-time visitor.
- Plan image URLs as part of the campaign workflow. If the spring campaign goes live on the 1st at 08:00, prepare the page with the new image name in advance — don't plan to overwrite
campaign.jpgat 07:55.
Common misunderstandings
"I replaced the image in Dynamicweb, so everyone sees the new one now." Not necessarily. New visitors do; returning visitors may keep seeing their browser's cached copy until it expires — up to the full cache lifetime after their last visit.
"I cleared the image cache on the server, so the browser caches are cleared too." No. The server's generated image cache and the visitors' browser caches are unrelated. Browser caches live on visitors' devices, and nothing you do on the server reaches into them — a browser only picks up changes when it decides to contact the server again.
"There's an ETag, so browsers always check whether the image changed." No. The version label is only used after the cached copy is no longer fresh. Within the cache lifetime, the browser doesn't contact the server at all — a replaced image is only picked up once the browser checks back.
"A short cache time is always safer." No. It makes in-place replacements propagate faster, but it also removes most of the benefit of caching — slower repeat visits and more load, for every image, all the time. Using new file names for time-critical changes is both faster and free.
Summary
- Two caches are involved: Dynamicweb's generated image cache on the server (manages itself — replaced originals are regenerated automatically) and the browser cache on each visitor's device (holds copies for the configured cache lifetime, default 7 days).
- While a cached image is fresh, the browser doesn't ask the server anything — a replaced same-name image simply isn't noticed until the cache lifetime has passed.
- The ETag (version label) only comes into play when the browser checks back after expiry — at that point a replaced image is detected and the new version is downloaded.
- A new file name is the safest way to make every visitor fetch a new image immediately, because browsers cache by URL.
- A shorter cache lifetime propagates in-place changes faster, but trades away performance — change it deliberately, not as a reflex.