A browser cache stores copies of some web responses so the browser can reuse them instead of downloading the same data on every visit. Images, stylesheets, scripts, and sometimes the page document can be cached. When a cached response is reusable, a page can load with less network traffic.

Reusing a file depends on caching rules, not just on whether a copy exists on your device. Your browser may use a stored copy directly, ask the server whether that copy is still current, or download a replacement. These choices help balance faster loading with keeping content current.

Files in the Browser Cache

A web page often needs many separate resources. If a logo or stylesheet has not changed, fetching it again can waste time and bandwidth. A server can include HTTP caching instructions in its response, which help your browser decide whether to store and reuse the data. The page document and the files it loads can each have different caching instructions.

A browser cache normally serves just that browser and is known as a private cache. A shared cache, by contrast, can serve multiple users. A content delivery network, or CDN, can keep shared copies on servers between a website and its visitors.

Caching does not mean the browser stores every page forever. The server can mark a response as reusable for a limited period, require a check before reuse, or prevent storage. Browsers also manage space and may remove entries. Changing a file's URL can create a different cache entry, which is one reason websites use versioned names for static files.

What Does Fresh Mean?

A cached response is fresh while its age is less than its freshness lifetime, which can be set by the max-age directive in the Cache-Control response header. The browser can reuse a fresh copy without checking the server unless another instruction requires validation. Once the lifetime expires, the copy is stale. Stale does not automatically mean incorrect, but the browser normally needs to validate the copy or fetch a new response before using the resource again.

For example, if a server sends a new stylesheet response with a freshness lifetime of one hour, your browser may reuse that response ten minutes later without another download. After the hour, the browser may ask the server whether the stylesheet changed. During the fresh period, the server could change the file without the browser immediately discovering that update. Freshness describes permission to reuse a response, not proof that it is the newest version on the server.

How Does Revalidation Work?

A browser revalidates a cached response by asking the server whether the stored version can still be used. Servers can attach a validator such as an ETag or Last-Modified value to a response. An ETag identifies a version of the resource, while Last-Modified provides a modification timestamp. The browser can send the ETag in If-None-Match, or the modification time in If-Modified-Since, to make a conditional request.

If the resource has not changed, the server may return 304 Not Modified, allowing the browser to reuse the body it already has. If the resource has changed, the server returns a new response, commonly 200 OK, with the updated content. A 304 response still involves a network check but avoids sending the entire resource body again. Without a usable validator, a browser that needs a current copy may have to download the resource again even if it has not changed.

The no-cache directive generally requires the browser to validate a stored response before reusing it. The no-store directive instead tells HTTP caches not to store that response. These directives serve different purposes, so a response can be stored and still need a check on every reuse. Ordinary reloads can also trigger validation; a reload does not necessarily mean every file is downloaded in full.

Cookies, Local Storage, and the Cache API

A cookie is a small piece of data that a website asks your browser to store and send with later requests that meet the cookie's rules. Cookies may help maintain a signed-in session or remember a preference. A cookie is not a saved copy of an image or stylesheet, and having a cookie does not automatically make a cached response private.

Website scripts can use localStorage for key-value data associated with an origin, meaning a particular combination of scheme, hostname, and port. Unlike cookies, local storage values are not automatically attached to HTTP requests.

A service worker, which is a script that can handle requests separately from the page, can use the Cache API to store responses according to rules set by the website's code. That storage can support offline behavior but does not automatically follow HTTP caching headers. The website's code controls when those entries are updated or deleted, so an old page can come from a storage layer other than the ordinary HTTP cache.

When Should You Clear the Cache?

Clearing cached files can help when one browser keeps loading an old image, stylesheet, or script after a site update. First, reload the page and compare it in another browser or device. If you see the same problem in both browsers or on both devices, the cause may be the server or a shared cache. Clearing all browsing data as a first step can sign you out of websites and may not change the response the server provides.

Before deleting data, review which categories the browser has selected. Cached images and files, cookies, and saved passwords can have separate controls, and deleting one category is different from deleting everything. After you clear cached files, your browser may need to download them again on your next visit.

If you manage the website, check its response headers, validators, file URLs, and network responses before asking visitors to clear their cache. An old file that persists after an update may reflect an incorrect caching policy or a missing version change. If you contact the site owner, include the page URL, the affected image or file, when you noticed the problem, and whether reloading the page or using another device changed the result.