The panel above writes a short-lived first-party cookie on this hostname, reads it back, and inspects whether localStorage, sessionStorage, and IndexedDB are usable in your current session. It also reports the Do Not Track and Global Privacy Control signals if your browser exposes them. What it cannot do is count third-party cookies (those require an embedded iframe from another origin) or list cookies marked HttpOnly (those are hidden from JavaScript by design). I built this page after a Stripe checkout outage that took me hours to diagnose because I had no quick way to confirm cookies were being written in the user's browser.
What this page actually tests
This is a first-party diagnostic. Everything it checks is scoped to the interaction between your browser and whatismytools.com. It cannot see your browser's state on other sites and it cannot see HttpOnly cookies. Inside that scope, four checks run.
- First-party cookie write and read. A uniquely named cookie is set with
SameSite=Laxand immediately read back. If the read succeeds, cookies work for this origin in your current session. - Web Storage.
localStorageandsessionStorageare probed with a write and read of a small string. Both can fail independently of cookies, especially in private browsing modes. - IndexedDB. A test database is opened and closed. Failure here usually means a hardened privacy profile or a kiosk mode policy blocks persistent storage.
- Privacy signals. The page reads
navigator.doNotTrackandnavigator.globalPrivacyControlif exposed. Absence does not mean you have no privacy rights; it just means your browser is not advertising an opt-out preference programmatically.
Notably, the panel does nottell you how many cookies are stored on your machine, what third parties have set cookies on other sites, or which advertising partners can recognize you cross-site. Browsers intentionally hide that information from JavaScript. For those answers, use your browser's built-in storage inspector (DevTools → Application → Storage in Chrome and Edge, Storage Inspector in Firefox, Storage tab in Safari Web Inspector).
First-party vs third-party cookies in 2026
A first-party cookie is set by the site whose URL is in your address bar. A third-party cookie is set by a different origin embedded on the page, typically via an <iframe>, <img>, or third-party script. Both kinds use the same HTTP cookie mechanism defined in RFC 6265; the difference is purely about whose origin set them and which site they get sent back to.
For two decades the advertising industry used third-party cookies to recognize users across sites. A tracking pixel on news.example.com and the same tracking pixel on shop.example.com both read the same third-party cookie, letting the tracker build a profile spanning both visits. That model is being dismantled.
The current state of third-party cookies, by browser:
- Safari has blocked third-party cookies by default since 2020, via Intelligent Tracking Prevention (ITP). The block is total: no third-party cookies are sent, even with user consent.
- Firefox blocks tracking cookies by default through Enhanced Tracking Protection (ETP), using a maintained list of known trackers. Strict mode blocks all third-party cookies; standard mode (the default) blocks known trackers and partitions the rest per top-level site.
- Brave blocks all third-party cookies and storage at the shield level. Aggressive shields also randomize fingerprinting signals.
- Chrome spent five years promising to phase out third-party cookies, then reversed course in 2024 and now offers a choice through Privacy Sandbox. Third-party cookies are still allowed by default in Chrome unless the user opts into the new tracking protection.
- Edge uses a Balanced default that blocks known trackers without blocking all third-party cookies.
The replacement mechanism for legitimate cross-site state (federated login, embedded payment widgets) is CHIPS (Cookies Having Independent Partitioned State). A site sets a cookie with the Partitioned attribute, and the browser stores it scoped to the top-level site that loaded the embed. This is the right way to ship embedded widgets in 2026.
How tracking protection got here
Browser tracking protection evolved in three rough waves, and where each browser sits today reflects the wave they bought into.
Wave one (2014 to 2018): user opt-in. Browsers shipped settings to block third-party cookies. Almost nobody used them. Do Not Track was added as a header signal. Almost no sites honored it. This era proved that an opt-in model does not protect anyone who does not already know to opt in.
Wave two (2018 to 2023): default blocking with allowlists. Safari shipped Intelligent Tracking Prevention in 2017 and made it the default. Firefox followed with Enhanced Tracking Protection. Both use a list of known trackers maintained by the browser vendor, plus heuristics to detect cross-site recognition. Brave was built on this premise from day one. WebKit's ITP documentation is still the clearest write-up of how it works.
Wave three (2024 onward): structured replacements.Chrome's Privacy Sandbox tries to offer privacy-preserving replacements for ad targeting: Topics API (interest categories computed locally), Attribution Reporting (ad conversion measurement without identifying users), CHIPS (partitioned cookies). Firefox and Safari are skeptical and have not adopted them. The result is a messy mid-2020s where what works depends heavily on which browser you are on.
Cookie attributes that actually matter
A cookie is a key-value pair plus a small set of attributes that control where and how it is sent. Five of those attributes do most of the work in production systems.
Set-Cookie: session_id=abc123;
Domain=example.com;
Path=/;
Max-Age=2592000;
Secure;
HttpOnly;
SameSite=Lax;
Partitioned- Secure: the cookie is only sent over HTTPS. Required for session cookies on any non-trivial site. Required for any cookie with
SameSite=None. - HttpOnly: the cookie cannot be read from
document.cookie. Required for session tokens to prevent XSS-based theft. This page reports an HttpOnly cookie as “not visible” because it cannot see it; that is the correct behavior and means the site is doing the right thing. - SameSite:
Strictsends the cookie only on same-site requests,Laxalso sends it on top-level navigations,Nonesends it on all requests but requiresSecure. The default since Chrome 80 isLax, which broke many embedded integrations in 2020 and is still the cause of half the cookie bugs I see. - Max-Age: lifetime in seconds.
Expiresis an older equivalent using an absolute date. Without either, the cookie is a session cookie and dies when the browser closes. Safari ITP caps client-set persistent cookies at seven days regardless of what you specify. - Partitioned: opts the cookie into CHIPS storage when the cookie is loaded in a third-party context. Without it, modern browsers reject or sandbox third-party cookies.
How to clear cookies properly
“Clear all cookies” is rarely what you want. It logs you out of everything, breaks your shopping carts, and resets every site's preferences. Per-site clearing is usually the right tool.
Chrome and Edge: Click the padlock in the address bar → Cookies and site data → review and delete entries for the current site. To clear everything: Settings → Privacy and security → Clear browsing data → Cookies and other site data.
Firefox: Settings → Privacy & Security → Cookies and Site Data → Manage Data lets you delete cookies for individual sites. The padlock in the address bar also offers Clear cookies and site data.
Safari: Settings → Privacy → Manage Website Data. You can search by site and remove specific entries. Safari also auto-deletes cookies from sites you have not visited in 30 days, per ITP.
One catch: deleting cookies does not delete localStorage, sessionStorage, or IndexedDB. A site that stores its session in localStorage will survive a cookie clear. Browser UIs label this collection as “site data” or “cached web content” depending on vendor. To fully reset a site, delete site data in the storage inspector or use the browser's “clear all site data” option for that origin.
Browser tracking protection compared
A client's checkout page worked in Chrome but threw “session expired” for about one in five Safari users. The session token cookie was set with a 30-day expiry, but Safari's ITP capped it at seven days because it was set by JavaScript instead of a server-side Set-Cookieheader. Customers returning after a week were silently logged out. The fix was to move session issuance to the server with a Secure, HttpOnly, SameSite=Lax cookie. The panel on this page would have surfaced “cookie present, JS-set, expires in seven days” in seconds; without it I spent an afternoon reading ITP documentation.
| Browser | Third-party cookies | Fingerprinting protection | Default |
|---|---|---|---|
| Chrome | Allowed (Privacy Sandbox opt-in) | Limited (Privacy Sandbox APIs) | Off |
| Safari | Blocked by default (ITP since 2020) | Strong (ITP + script restrictions) | On |
| Firefox | Blocked or partitioned (ETP) | Strong with resistFingerprinting | Standard on |
| Brave | Blocked by default | Aggressive randomization | On |
| Edge | Known trackers blocked (Balanced) | Limited | Balanced on |
| Arc | Blocked (DuckDuckGo lists) | Limited | On |
Frequently asked questions
What are third-party cookies?
A third-party cookie is set by a domain other than the one in your address bar, usually via an embedded image, iframe, or script. They were the backbone of cross-site advertising tracking. Safari, Firefox, and Brave block them by default; Chrome and Edge still allow them but offer opt-in protections. CHIPS partitioned cookies are the supported way to ship third-party cookies for legitimate purposes in 2026.
Are cookies bad for my privacy?
First-party cookies are how websites remember you are logged in and keep your shopping cart. They are essential and low-risk. Third-party cookies were historically used to track you across sites, which is why every major browser except Chrome now blocks them by default. The cookie mechanism itself is neutral; the use case determines the privacy impact.
How do I know if my browser is blocking trackers?
Use the EFF's Cover Your Tracks test, which loads known tracker domains and reports which were blocked. Brave and Firefox also surface a shield icon in the address bar showing what was blocked on the current page. In Chrome, the Privacy Sandbox tab in settings shows your current protection state.
What is the difference between cookies and localStorage?
Cookies are sent automatically to the server on every request, are limited to about 4 KB each, and can have security flags like HttpOnly. localStorage is accessible only from JavaScript, holds about 5 to 10 MB, and is never sent over the network. Use cookies for session tokens that the server needs; use localStorage for client-side preferences and cached UI state.
Why do I keep having to log in to websites?
Three common causes. First, Safari's ITP caps JavaScript-set cookies at seven days, so any site that issues session cookies from the client logs you out after a week. Second, private browsing modes delete all cookies when the window closes. Third, aggressive cookie or storage clearing extensions wipe state between sessions. If only one site keeps logging you out, the issue is on their side; if every site does, your browser is clearing too aggressively.
Related tools
The browser doing the storage and the version it runs are on What Is My Browser. The raw User-Agent string sites read to make tracking decisions is on What Is My User Agent. GPU and WebGL fingerprinting signals are on What Is My WebGL / GPU. For the IP your tracking cookies would be associated with, see What Is My IP.
Sources cited above
- RFC 6265: HTTP State Management Mechanism (cookies, 2011)
- WebKit Tracking Prevention Policy: Safari Intelligent Tracking Prevention
- Google Privacy Sandbox: CHIPS partitioned cookies
- Mozilla: Firefox Enhanced Tracking Protection
- Global Privacy Control: specification and supporting browsers
- EFF Cover Your Tracks: browser tracker blocking test