Canonical article: https://www.awahab.dev/blog/why-clearing-cache-fixes-things Author: Abdul Wahab (https://www.awahab.dev/) Engagement: 40 likes, 680 views, 1 comments # HTTP caching and stale responses Published: 2026-10-09T00:00:00.000Z Updated: 2026-10-14T09:54:11.663Z How fresh and stale responses work, with Cache-Control rules and a version check that can avoid a download. Clearing your browser cache removes saved responses, so the next request can fetch a newer version. It does not change the server or clear a CDN's cache. If your browser shows an old page while a friend sees the update, the difference may be in which cached response each browser can reuse. ## A saved copy with permission to reuse it Imagine copying a café menu into your notebook. Checking the notebook is quicker than walking back to the counter. The trade-off is that the café might change its menu while your copy stays the same. An HTTP (Hypertext Transfer Protocol) cache keeps a response so a later request can reuse it. A browser cache lives on your device. A shared cache, such as a content delivery network (CDN), can serve many visitors. Reuse can avoid a request to the origin server. [MDN explains the different cache layers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching). The cache needs a rule for how long it can reuse a saved copy. Without one, visitors can receive confusing answers. ## A fresh response can differ from the server an example response ```http HTTP/1.1 200 OK Cache-Control: max-age=60 ETag: "menu-v1" ``` Here, `max-age=60` gives the response a freshness lifetime of 60 seconds. During that time, an ordinary request can reuse the stored response. If the café changes its menu after ten seconds, the saved copy can still count as fresh under this rule. ![Notebook diagram showing a browser cache holding version 1 while the origin server has version 2. The cached response can be reused until its freshness timer expires.](https://media.awahab.dev/cache-freshness.png) Your browser can reuse the old page until its cache timer expires. Once the response is stale, the cache needs another way to decide whether it can reuse it. In this example, it asks the server to validate its copy. The [Cache-Control reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control) explains the headers. > In the sketch above, publish a new version. Then request the page. Advance time past 60 seconds. Request it again. The server changes immediately, but the cached copy follows its freshness rule. ## Revalidating a saved response The server supplies a version identifier called an `ETag`. The client can send its saved identifier in an `If-None-Match` request header. If the identifier still matches, the server can answer `304 Not Modified` without sending the response body again. If it differs, the server returns the new representation. [ETag reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag). the version check ```http GET /menu HTTP/1.1 If-None-Match: "menu-v1" # If the server still has menu-v1: HTTP/1.1 304 Not Modified ``` The cache checks for an update and can still reuse the bytes it already downloaded. To see this in the sketch, request an expired copy without publishing an update. ## Clearing the browser cache After you remove the saved response from your browser, its next request cannot use that local copy. This can reveal a newer version. It does not automatically empty the cache in a CDN or an application. Those are separate layers. Which cache supplied the response? Inspect the request in the Network panel of your browser. Check the response headers. Compare a normal load with one that bypasses the browser cache. [MDN covers reloads and stored responses](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching#reload_and_force_reload). Suppose three colleagues see different versions. Record who saw each version and when. Then inspect the cache headers. That timeline can make the freshness rule easier to understand. ## Three rules worth recognizing Directive | Meaning --- | --- max-age=60 | Allow reuse while the response is fresh for 60 seconds. no-cache | Allow storage. Validate before reuse. no-store | Do not store the response in an HTTP cache. Despite its name, `no-cache` permits storage. It requires validation before reuse. `no-store` prevents storage. These directives control HTTP caching. An application can also manage separate caches. [Cache-Control reference](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control). For practice, open the Network panel on any public page. Select one document and one image. Compare their caching headers. Would you accept the same freshness lifetime for both resources? Explain your choice. ## Takeaway A cache can treat a response as fresh even after the server changes. Choose its freshness rules deliberately. ## Sources - [MDN: HTTP caching](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching) - [MDN: Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control) - [MDN: ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/ETag) ## Keep reading - [Idempotency and duplicate requests](https://www.awahab.dev/blog/duplicate-requests-and-idempotency) ## Comments **Sam** — 2026-10-13T13:53:25.556Z > Always assumed no-cache meant nothing gets stored. That naming is so confusing lol. - **Abdul Wahab (author)** — 2026-10-13T13:53:25.563Z > Yeah, the name trips people up. It can store the response, but has to validate it before reusing it.