Browser cache

What it means

A browser cache can keep a previously received HTTP response and reuse it when the HTTP caching rules permit. The response has a freshness lifetime, may need validation with the origin, or may be ineligible for storage. Reuse is conditional; it is not a promise that a browser will store every resource. HTTP caching standard

The browser's HTTP cache is different from a DNS resolver cache (name-to-address answers) and from a CDN edge cache (shared responses near visitors). Refreshing one layer does not automatically clear another.

Try it

Simulation — replay one browser HTTP cache. Load the synthetic resource, advance time, force validation or change the origin version. The result identifies local reuse, a bodyless 304 or a new 200 response; it does not read or clear your real browser cache.

Load at t=0 to save v1 with a 60-second freshness lifetime. Advance to t=30 and load again: the scene reuses v1 without a network response. Advance to exactly t=60: the entry is stale. With the unchanged ETag, the local conditional exchange returns 304 and uses the stored v1 body. Change the origin version and force validation to receive a new 200 body.

The policy selector describes the next origin response. Merely choosing no-store does not alter an existing entry or cause a fresh cached response to contact the origin. After an actual network response with no-store, this fixture keeps any earlier body only as an ineligible trace; it must not satisfy a later load. That is not proof that a real browser physically erased older copies. The explicit Evict action affects only the synthetic entry.

Private allows storage in this private cache under the other modeled conditions; it is not encryption. No-cache allows storage but requires validation. Reset clears the synthetic entry, origin changes, clock and history. There is one representation, no Vary, no shared cache, no service worker and no network-delay/Age calculation; virtual elapsed time supplies response age. Caching and validation rules 304 semantics

Understand these response controls

The Vary field can require selected request-header values to match before a stored response is reused. Other restrictions apply to methods, response codes, authorization and freshness calculations. Cache directives

Diagnose stale content

1. Inspect the exact URL and response headers in browser developer tools. The address may differ by query or a redirect.
2. Determine whether the browser reports a network transfer, local cache reuse, validation or service-worker handling. A service worker has its own logic and is not synonymous with HTTP cache.
3. Compare the response with the CDN or origin only after identifying which layer served it. A browser reload is not a universal cache purge and not a DNS-change test.
4. For files that must remain available to already-open pages across deployments, consider versioned/content-hashed asset URLs together with compatible retention. For sensitive personalized responses, review the entire cache policy and shared intermediaries rather than assuming private means encrypted.

In practice

Use freshness for stable resources, validators for resources that may change, and a deliberate policy for personalized data. Compare with CDN for shared edge behavior and DNS TTL for an entirely different cache lifetime. If a real page is missing, HTTP 404 troubleshooting helps separate missing routes from stale content.

Key takeaways

Ask three separate questions: may the response be stored, may it be reused now, and must it be validated? A 304 needs a corresponding stored body; it is not an empty replacement page. No-cache is not no-store, and changing a server policy is not a universal cache-deletion command.