Syllabus Lesson 13 of 156 · Cookies, properly explained
Cookies, properly explained

Beyond cookies

Why it matters Clearing cookies feels like a fresh start, but cookies are only one of several drawers a site can keep a label in. Knowing the other drawers tells you what "clear site data" really needs to cover.

If cookies are the coat ticket, the other storage areas are the other pockets of your coat. A note left in an inside pocket is still there after you hand back the ticket.

Web storage: places in your browser where a site can keep data for itself. Unlike cookies, most of these are not sent to the server automatically; a page script reads them and can then send what it finds.

Identifier (ID): any value that is unique to you or your browser, such as u-7731. Wherever an ID can be stored and read back later, it can be used to recognise you.

The main drawers

  • localStorage: a simple notebook of names and values that stays until the site or you remove it. Sites use it for settings, drafts and, sometimes, IDs.
  • sessionStorage: the same idea, but forgotten when you close the tab.
  • IndexedDB: a larger database inside the browser, used by web apps that work offline, such as email or note apps.
  • Cache: copies of pictures, scripts and pages saved so the site loads faster next time. Sites and browsers manage it.
  • Service workers: small background scripts a site can install to work offline and show notifications. They can keep their own storage too.

How an ID can hide

A tracker script could write uid=u-7731 into a cookie and into localStorage. If you clear only cookies, the script finds the copy in localStorage and writes the cookie back. Older trackers called this a supercookie or "zombie cookie", because it comes back after you think it is gone.

Even the cache could be used. A server can attach a short tag to a cached file, and your browser politely repeats that tag the next time it checks whether the file has changed. If the tag is unique to you, it works like an ID. The deep half of this course shows how engines close these gaps.

Partitioning covers more than cookies

The good news: modern browsers partition these drawers too. An embed on shopa.example gets a different localStorage, IndexedDB and cache from the same embed on shopb.example. The HTTP cache has been partitioned in Safari since 2013, in Chrome since version 86 and in Firefox since version 85 (checked October 2026). So hiding an ID in another drawer no longer helps a third party join sites.

What partitioning does not stop is a first party remembering you on its own site. That is why clearing a site's data should clear every drawer, not just cookies.

A common misconception

"Clearing cookies resets everything." Most browsers offer two options: clear cookies, or clear all site data. Only the second empties every drawer. Look for wording like "cookies and site data".

Try it

Open your browser's developer tools (DevTools): press F12, or Ctrl+Shift+I on Windows and Linux, or Cmd+Option+I on a Mac. In Safari, first switch on "Show features for web developers" in Settings, Advanced. DevTools is a built-in panel that shows what a page is doing. Looking is always safe: nothing you see there is sent anywhere.

  1. Open a web app you use, such as a mail or notes site, and open DevTools.
  2. Go to Application (Chrome, Edge) or Storage (Firefox, Safari).
  3. Open Local storage and IndexedDB in the left list and look at what is there. You are only looking; do not delete anything you need.

Recap

  • Besides cookies, sites can store data in localStorage, sessionStorage, IndexedDB, the cache and service workers.
  • An ID copied into several drawers can bring a deleted cookie back.
  • Modern browsers partition these drawers too, so third parties cannot join sites through them.
  • To reset a site fully, clear all site data, not just cookies.

Spotted a problem in this lesson? Report it

Code · runs in your browser
Output