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

Example — a reusable CSS response. This illustrative header sequence is not a captured browser session.

HTTP/1.1 200 OK
Content-Type: text/css
Cache-Control: private, max-age=60
ETag: "revision-4"

/* illustration */

During an eligible 60-second freshness window, a private browser cache can reuse this representation without a network request. When it becomes stale, it may send a conditional request:

GET /styles.css HTTP/1.1
Host: www.example.com
If-None-Match: "revision-4"

HTTP/1.1 304 Not Modified
ETag: "revision-4"

A valid 304 tells the cache it can update and reuse the stored representation; the 304 response itself does not include the original CSS body. Actual request/response framing and validator choices depend on the client and server. Validation

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.