Storage & Cookies · Privacy Tests
Cookies & Storage Test
Check whether cookies, local storage, session storage and IndexedDB are available right now.
Storage mechanisms
Each test tries to write and read back a small value, then deletes it immediately. Nothing persists and nothing is sent anywhere. Third-party cookie behaviour depends on the embedding site and is not tested here.
On this page
What this test checks
Websites can store small amounts of data in your browser to remember you, keep you logged in, or save your preferences. This test checks, live and harmlessly, which of those storage mechanisms your browser will currently allow: cookies, local storage, session storage and IndexedDB. It writes a tiny test value into each, reads it back, and cleans up after itself.
The mechanics are deliberately simple. For each mechanism the page attempts a write, then a read, then a delete, and treats any thrown exception as a block. A browser that has cookies switched off will refuse the write, and a browser in a hardened private mode may accept it and then discard it, so the round trip is the only honest way to tell. Because the check happens in this tab, the result describes this page’s own origin and nothing else.
Nothing is left behind
Every value the test writes is deleted the instant it has been read. The check tells you what is possible, without actually storing anything or sending a byte to a server.
The four storage types
| Type | Lifetime | Sent to server? |
|---|---|---|
| Cookies | Until they expire or are cleared | Yes, on every matching request |
| Local Storage | Until manually cleared | No, read by scripts only |
| Session Storage | Until the tab closes | No, read by scripts only |
| IndexedDB | Until manually cleared | No, larger structured data |
Cookies are the only type sent to the server automatically, which is both what makes them useful for logins and what makes them central to tracking.
The four differ in size as well as lifetime. A single cookie is limited to roughly 4 kilobytes, and browsers cap how many a domain may set. Local and session storage each offer around 5 megabytes per origin, which is plenty for a few settings but not for large files. IndexedDB is the outlier: it stores structured records and databases and is granted a quota that scales with the free space on your disk, which is why offline web apps lean on it.
First-party versus third-party
The single most important distinction in storage is who set it. A first-party cookie belongs to the site in your address bar, the one keeping you logged in. A third-party cookie is set by a different domain embedded in the page, an advert or a social widget, and it is what lets a company recognise you across many unrelated sites.
Browsers increasingly block third-party cookies by default while leaving first-party ones alone. Safari has blocked them for years through Intelligent Tracking Prevention, Firefox isolates them per site, and Chromium browsers are moving the same way. That is why this test can report cookies as working even when a site complains they are blocked: it is writing a first-party cookie, and your browser may still be refusing third-party ones. That split is deliberate and, for privacy, a good thing.
The two are controlled separately in your settings, and the local storage test and IndexedDB test drill into the other two mechanisms on their own.
Cookie attributes that matter
A cookie is more than a name and a value. Every one carries attributes that decide how it behaves, and they explain a lot of confusing behaviour. Secure means the cookie is only ever sent over HTTPS, so it cannot leak on an insecure connection. HttpOnly hides it from JavaScript entirely, which is why a login cookie set this way is invisible to scripts but still travels to the server.
SameSite controls whether the cookie is attached to cross-site requests. Strict withholds it whenever you arrive from another domain, Lax sends it on ordinary top-level navigation, and None allows it anywhere but requires Secure. The Domain and Path attributes decide which URLs receive it, and an expiry date distinguishes a persistent cookie from one that dies with the session.
None of this is visible from JavaScript when a cookie is HttpOnly, which is why a storage check in a page cannot report on everything your browser holds.
If storage is blocked
If the test shows cookies or storage blocked and something is not working as expected, a few things are usually responsible.
- Private or incognito mode. Storage still works but is wiped when the window closes, and some browsers restrict it further.
- Strict privacy settings. A browser set to block all cookies, or an extension doing so, will fail these tests by design.
- Embedded context. If this page is inside an iframe on another site, it may be treated as third-party and blocked.
To fix it for a specific site, allow cookies for that domain in your browser settings rather than enabling everything globally. If a login keeps dropping even so, the evercookie test shows how stubbornly some identifiers can be re-created after you clear them.
Storage and tracking
Storage-based tracking works by saving an identifier on your device and reading it back later. Its great weakness, from a tracker’s point of view, is that you can delete it: clear your cookies and the identifier is gone. That is why the storage arms race exists, with trackers writing the same value in several places at once so a partial clear does not lose you.
Evercookie techniques do exactly this, planting a value in cookies, local storage, IndexedDB and elsewhere, then repairing whichever copies you delete from the ones that survive. Clearing one mechanism can be worse than useless if the others re-plant it on your next visit, which is why a full clear of site data is the only reliable reset.
Why clearing cookies is not enough
Fingerprinting was invented precisely to survive cookie clearing. It stores nothing and instead measures your device, so it re-identifies you even after a full wipe. See the fingerprint test to understand the technique that storage controls cannot touch.