Cookies, Local Storage, Cache, and Browser Fingerprints Explained

These concepts often appear together in privacy settings, debugging instructions, and browser-profile products. They behave differently enough that “clear the browser” is an incomplete instruction.

A working mental model

Mechanism	Who creates or controls it	Normal scope	Common purpose	Sent automatically with a request?
HTTP cookie	A server sets it; the browser stores and returns it under scope rules	Host or domain, path, lifetime, and connection conditions	Session identifiers, preferences, anti-abuse state	Yes, when the request matches its scope
localStorage	Site JavaScript	Origin, subject to browser partitioning and policy	Persistent key-value application state	No
sessionStorage	Site JavaScript	Origin within a top-level browsing session	Temporary tab or workflow state	No
HTTP cache	Browser and HTTP caching rules	Cache key, response directives, browser policy	Reuse responses to reduce latency and traffic	It may satisfy or revalidate a request
Cache Storage API	Site or service-worker JavaScript	Origin or storage partition	Offline resources and application-managed responses	No automatic attachment; script controls use
Browser fingerprint	A site or other observer measures signals	Depends on observer and signals	Security, fraud detection, analytics, or tracking	Some signals are visible in requests; others require active code

The first five rows involve retained state. The last row is an observation and correlation method, although retained state can also become one of its inputs.

Cookies: server-facing state with scope rules

HTTP itself is mostly stateless. Cookies let a server give the browser a name-value pair and receive it on later matching requests. RFC 6265 defines the Set-Cookie response header, the Cookie request header, and the browser’s storage model.

A cookie can be:

• session-scoped, retained until the browser-defined session ends;
• persistent, with an expiry or maximum age;
• host-only, returned only to the host that set it;
• domain-scoped, eligible for the specified domain and matching subdomains;
• path-scoped, returned only for matching request paths;
• Secure, returned only over a secure channel as defined by the browser; and
• HttpOnly, withheld from script-facing cookie APIs while remaining available to HTTP requests.

Those attributes affect delivery and script access. They do not turn the cookie value into an independent security boundary. RFC 6265 specifically warns that the Path attribute should not be relied on for security, and it recommends secure transport and additional protection for sensitive cookie contents.

Why deleting cookies signs you out

Many services store a random session identifier in a cookie while keeping the account record and session details on the server. Deleting that cookie removes the browser’s copy of the identifier, so the next request no longer presents the same session. The server-side account and other sessions may remain.

This also explains why copying authentication cookies is sensitive. A usable session identifier may act like a credential. Do not paste raw cookies into tickets, logs, automation output, or team chat.

Local storage: script-controlled state for one origin

The HTML Standard defines localStorage as access to an origin’s local storage area. It is intended to span windows and last beyond the current session. The storage contains string key-value pairs and is available to script running with access to that origin.

An origin normally combines scheme, host, and port. As a result, these are different storage scopes:

• https://app.example.test
• http://app.example.test
• https://admin.example.test
• https://app.example.test:8443

The URL path is not part of the origin. Pages at /billing/ and /support/ on the same origin can address the same local storage area unless the application creates its own logical separation.

Unlike a cookie, a localStorage entry is not automatically attached to HTTP requests. Site script must read it and decide what to do. This makes it useful for interface preferences, draft state, and application data, but any script executing with the origin’s authority may be able to access it. Sensitive session designs should account for script compromise rather than assuming that “local” means secret.

Persistence here means that data can survive a browsing session. It does not mean permanent retention. A person can clear the data, browser policy can restrict it, and a browser can apply storage and eviction rules.

sessionStorage is a different lifetime

sessionStorage is associated with the origin and a top-level browsing session. It is suited to state that should remain while a tab or window workflow continues and then end with that session. A cloned or restored tab can involve browser-specific lifecycle details, so applications should not use it as the only record of critical work.

Local storage is only one site-data mechanism

Modern web applications may also retain data in IndexedDB, Cache Storage, service-worker registrations, the Origin Private File System, permissions, and other browser-managed stores. Clearing only localStorage in developer tools can therefore leave other state intact.

The HTML Standard’s privacy guidance recommends that browsers let people clear persistent storage mechanisms together, because sites could otherwise use one store to recreate an identifier removed from another.

Cache: one word for several mechanisms

The HTTP cache

RFC 9111 defines an HTTP cache as a store of response messages plus the system that controls their storage, retrieval, and deletion. A browser cache can reuse a fresh response or revalidate a stale one, reducing latency and network transfer.

The cache key includes at least the request method and target URI, and response headers influence whether and for how long a response can be reused. The HTTP cache is an optimization layer. A cached image or script does not normally mean that the person is signed in.

Cache state can still affect privacy. Timing or whether a resource is already available may reveal information in some threat models. The W3C’s fingerprinting guidance includes cached-resource observations among the ways browser or user configuration can be inferred.

Cache Storage and service workers

The Cache Storage API gives a site explicit, script-controlled Cache objects, often for offline web applications. The Service Workers specification states that these caches are separate from the browser’s HTTP cache, are isolated by origin, and are updated or deleted by application logic rather than ordinary HTTP freshness rules.

This difference matters during debugging:

• clearing “cached images and files” targets the browser’s ordinary cache;
• clearing site data can also remove Cache Storage and service-worker state; and
• reloading with the HTTP cache bypassed may still leave an active service worker controlling requests.

Name the cache you mean before deciding how to inspect or clear it.

Storage partitioning adds another key

Origin scope once allowed an embedded third party to read the same storage when it appeared inside many top-level sites. Modern browsers increasingly add the top-level site or related context to the storage key.

Chrome documents that its storage partitioning prevents an example.com frame embedded on a.com from automatically sharing Local Storage, IndexedDB, Cache Storage, service workers, and certain communication mechanisms with the same frame embedded on b.com. Chrome says this has been enabled for all users since Chrome 115, with later changes for some additional APIs.

Partitioning explains an otherwise surprising result: the same embedded origin may see different storage depending on the site around it. It does not mean all storage everywhere has one universal two-key model. Browser versions, top-level and embedded contexts, storage-access grants, enterprise policy, extensions, and API-specific rules can change the result.

Test the exact context rather than inferring it from the domain name alone.

Browser fingerprints: observed signals, not a folder

The W3C defines browser fingerprinting as the ability to identify or re-identify a user, user agent, or device through configuration settings or other observable characteristics. Its 2025 guidance separates several forms:

• Passive fingerprinting uses information already observable in requests or the network, such as request headers and IP address.
• Active fingerprinting runs code to observe characteristics such as window size, fonts, connected devices, performance, sensors, or graphical rendering.
• Transient event correlation links contexts through near-simultaneous device or environment changes.
• Cookie-like techniques store and retrieve state through mechanisms that may outlive or recreate ordinary cookies.

A fingerprint is rarely one immutable value stored by the browser. An observer chooses signals, combines them, and decides how strongly they match a previous visit. The result can change as the browser updates, the window changes, fonts are added, a device is connected, or the network route moves. It can also remain similar after cookies are cleared because many underlying signals are unchanged.

Fingerprinting is not proof of identity

A set of signals may be common across many people or may drift for one person. Sites can also combine a fingerprint with a login, server-side account history, network reputation, or stored identifiers. Recognition after clearing data therefore does not prove that fingerprinting alone was responsible.

For the same reason, changing one visible setting does not guarantee a new identity. A coherent, common configuration may reduce some uniqueness, while many unusual independent changes can create a rarer combination. These signals cannot support a guarantee of invisibility or third-party acceptance.

What common clearing actions actually change

Action	Likely effect	Important remainder
Delete cookies for a site	Removes matching browser-held cookie state and often signs out that profile	Server-side account data, other devices, and non-cookie stores may remain
Delete cookies and other site data	Can remove cookies, Web Storage, IndexedDB, service workers, and related site state, depending on browser UI and scope	Password manager, downloads, account-side data, and observable device signals are separate
Delete cached images and files	Removes ordinary cached response content	Cookies, local storage, and Cache Storage may require separate selection
Clear history	Removes recorded visited URLs and related suggestions in the selected scope	Downloaded files and site-held records remain
Remove a browser profile	Removes its local bookmarks, history, passwords, and other settings from the device	Synced account data, downloaded or exported files, backups, and server-side data may remain
Start a new profile	Begins with a different profile state collection	Device, OS, browser build, and network may still be observable as related

Chrome’s own browsing-data guide treats history, cookies and other site data, cached images and files, download history, autofill, site settings, and hosted app data as distinct categories. It also notes that deleting download history leaves the downloaded files on the computer and that signed-in data deletion can affect the Google Account and other synced devices.

The exact effect depends on the selected time range, profile, account state, browser version, and enterprise policy. Review the confirmation text before deleting data that may be difficult to recover.

How separate browser profiles affect each mechanism

A correctly separated persistent profile should have its own cookie jar, web storage areas, site databases, Cache Storage, HTTP cache ownership, history, site permissions, and extension state. This prevents profile B from simply inheriting profile A’s stored session.

Several signals can remain common:

• browser engine and version;
• operating system and hardware;
• installed system fonts and display characteristics;
• language, time zone, or accessibility settings inherited from the host;
• IP address and network path when no separate route is configured; and
• operator behavior or logins that link activity at the application layer.

Different profiles can also expose different signals through their extensions, permissions, window sizes, language settings, or proxy routes. The net effect is implementation- and context-dependent. Profile separation should be evaluated as state isolation, not as a fingerprint guarantee.

Diagnose the symptom before clearing everything

“I was signed out”

Check cookies first. A session cookie may have expired, been deleted, been rejected under a browser policy, or been invalidated by the server. Local storage can support the interface, but it is not normally the cookie automatically sent to authenticate an HTTP request.

“The site forgot my draft or offline data”

Inspect local storage, IndexedDB, Cache Storage, and service-worker state. Confirm the origin and whether the page is top-level or embedded in another site, because partitioning can change the available storage.

“The first reload is slow”

An empty or stale HTTP cache is a likely factor. Network, server, and service-worker behavior can produce the same symptom, so record request timing and cache status before concluding.

“The site still recognizes the environment after I cleared data”

Several explanations remain: the account is still signed in elsewhere, the server linked the visit through account or network data, another browser store survived, or observable characteristics correlated the sessions. Treat fingerprinting as one hypothesis, not the automatic answer.

Decision-oriented takeaway

Use the mechanism to choose the remedy:

• inspect or clear cookies when the question concerns server sessions;
• inspect origin-scoped site stores when a web application retains local state;
• distinguish the HTTP cache from Cache Storage when diagnosing stale or offline content;
• use a separate persistent profile when stored work state must remain independent; and
• treat fingerprinting as correlation across observable signals, with limits that clearing data or changing one setting cannot erase.

This model avoids two costly mistakes: deleting more state than necessary and assuming that an empty cookie store creates a new device identity.

Limitations

Web storage and privacy behavior evolves across browsers and releases. Third-party cookie rules, storage partitioning, eviction, sync, enterprise policy, extensions, and private-browsing modes can alter the behavior described here. The guide explains the standards and current Chrome documentation at the access date; it does not characterize every browser or website implementation.