Why do I still see the old version after I deploy?

What it actually is

The browser cache is storage on your device where your browser keeps copies of files a site already sent it (HTML, CSS, JavaScript, images) so the next visit doesn’t need to download all of it again. It’s separate from local storage and cookies, which hold data your app deliberately saved; the cache holds copies the browser fetched on its own, without your code asking for that.

Think of it as a photocopy you filed after your last visit to a page. The next time you open that page, your browser checks its own drawer before it checks the real archive. If nothing has told it the archive changed, it hands you the photocopy, even if the actual page behind it changed five minutes ago. That’s fine for the visits where nothing changed and frustrating for the one visit where it did, right after you shipped a fix.

Why your AI just did this

Your agent didn’t do anything wrong. Modern build tools like Vite and Next.js rename your JavaScript and CSS files with a content hash on each build, so those files load fresh the moment you deploy: a new hash means a new URL, and a new URL has no photocopy on file yet. The HTML document itself, and any asset that keeps the same filename between builds (a logo, an uploaded image), doesn’t get that automatic reset. Whether those get cached, and for how long, comes down to response headers your server, framework, or CDN sets, often without either of you touching them directly.

So your agent pushes the fix through Lovable, Bolt, or a git push that triggers a deploy on Vercel, and the new files are already on the server. Your tab just hasn’t asked for them yet. A normal refresh does ask, but if a cache sitting between you and the origin, like a CDN or a proxy, answers on the server’s behalf instead of forwarding the question along, you can refresh all day and still get the old answer back.

When you’ll run into it

The classic version: you or your agent fixes a bug, you reload the tab, and the broken button or the old wording is still right there. Someone testing on a different device sees the fix fine, which makes it look random. Usually the explanation is two tabs with different cache histories.

Open DevTools (F12 on Windows and Linux, Cmd+Option+I on Mac) and watch the Network tab while you reload: any request whose Size column names a cache instead of a file size (Chrome labels these disk cache or memory cache, worded slightly differently across versions) came straight from your machine, not the server. If an image looks stale, also rule out lazy loading: a picture that hasn’t scrolled into view yet may simply not have loaded, which looks identical to a cached one until you scroll down to it.

What to check

• Open the page in a private or incognito window first. It starts without your regular browsing cache, so if the fix shows up there, caching was the whole story
• Force a real reload: Ctrl+Shift+R or Ctrl+F5 on Windows and Linux, Cmd+Shift+R on Mac, in Chrome, Firefox, and Edge
• In Safari, hold Shift and click Reload, or turn on the Develop menu (Safari Settings, Advanced) and use Empty Caches for a full clear
• With DevTools open, check the “Disable cache” box in the Network panel, or right-click the reload button in Chrome for “Empty Cache and Hard Reload.” Both only apply while DevTools stays open
• If an incognito window still shows the old version, stop blaming your browser. Open your deploy dashboard and confirm the latest build actually succeeded and is the one marked Production, not a preview sitting unpromoted next to it
• If your host reuses a build cache to speed up installs between deploys, redeploy without it (Vercel’s Redeploy dialog has an option to skip “Use existing Build Cache”) to rule that out too

Say it like a dev

Instead of: “I fixed it but the site still looks the same” Say: “The deploy succeeded but a hard refresh still shows the old version. Can we check whether this is a caching issue rather than something in my code?”

Instead of: “just tell me to refresh again, it still doesn’t work” Say: “I tested this in an incognito window and still see the old version, so it’s probably not just my browser’s cache. Can you check the deployment log for the actual production build?”

Instead of: “the CSS looks old even though I already changed it” Say: “The stylesheet might be getting served from cache under the old filename. Can you add a cache-busting hash to the file name so browsers know to fetch the new one?”