Cookies, Local Storage and Partitioning: Who Can Store What in Your Browser

"Cookies" has become shorthand for all the ways websites remember things in your browser. In reality there are several storage mechanisms, and modern browsers treat them very differently depending on one question: are you storing data for the site in the address bar, or for something embedded inside it?

The storage mechanisms

• Cookies are small name–value pairs that the browser sends back to the server with matching requests. That is why logins rely on them. Attributes such as Secure, HttpOnly and SameSite control when a cookie is sent and whether scripts can read it.
• localStorage holds strings that persist until cleared. sessionStorage holds strings for one tab and forgets them when it closes. Neither is sent to the server automatically.
• IndexedDB is a transactional database in the browser, used by web apps that work offline or handle large amounts of data.
• Cache Storage lets service workers keep copies of network responses.

All of them are scoped to an origin: the scheme, host and port of the site that wrote them.

First-party and third-party contexts

When you visit news.example, that site is the first party. If the page embeds a video player, an ad, or a "like" button from another domain, those embeds run in a third-party context. They can try to store data too.

Third-party storage is what made cross-site tracking easy. An ad server embedded on thousands of sites could set one cookie, see it on every one of those sites, and build a browsing history. Browsers have since taken three different paths.

How the major browsers differ

Safari has blocked third-party cookies by default since Safari 13.1 and iOS 13.4 (March 2020).

Firefox uses State Partitioning, on by default since Firefox 103. Third-party storage still works, but it is double-keyed: by the embedded site and by the top-level site. The same embedded player on two different sites gets two separate, unconnected cookie jars. Firefox also partitions network state such as the HTTP cache.

Chrome still allows third-party cookies by default. Google had planned to phase them out, but in April 2025 announced it would keep its current approach of letting users choose in Chrome's privacy settings, and would not introduce a separate prompt.

Two newer mechanisms bridge these approaches:

• Partitioned cookies (CHIPS). A cookie set with the Partitioned attribute is stored per top-level site by design. That suits embedded chat widgets or maps that need state but shouldn't track across sites. It became Baseline across major browsers in 2025.
• The Storage Access API. An embedded iframe can ask for access to its unpartitioned cookies, usually after you interact with it and sometimes with a prompt. This is how "log in with" widgets keep working under strict defaults.

How much can a site store?

Quotas are generous but not unlimited. MDN documents that Chromium-based browsers let an origin use up to about 60% of the disk. Firefox allows the smaller of 10% of the disk or 10 GiB per group of sites in its default "best-effort" mode. Data in best-effort mode can be evicted when the device runs low on space. A site can ask for persistent storage, which the browser then only clears on your request.

Private windows

Private and incognito windows start with empty storage and discard all of it when they close. Sites can still store data during the session, which is why your login works until you close the window.

When a site keeps forgetting you

1. Check that the site's first-party cookies aren't blocked. The cookies and storage test shows which mechanisms work on BrowserProbe, and your browser's site settings show per-site rules.
2. If a login inside an embedded widget fails, the widget may need third-party storage. Allowing it for that one site is safer than turning protections off everywhere.
3. Extensions that block trackers sometimes block storage on sites you use. Try a window without extensions to find out.