How to see which cookies and trackers a website loads

Most people's only look at a site's cookies is the consent banner that shows up on arrival, and that banner is written by the site, not verified by anyone. If you want to know what's actually happening before you click "accept" or "reject," you have to look yourself. It takes about five minutes with tools already built into your browser.

Before you start

Two things skew what you'll see, so control for them first:

• Use a fresh, private window. A normal browsing window already carries cookies from your history, logins and any consent choice you made last time. Open a new Incognito window (Chrome) or Private Window (Firefox) so the site treats you as a first-time visitor.
• Don't click anything on the banner yet. The entire point is to see what loads before you answer, so load the page and go straight to the developer tools without touching the cookie prompt.

Chrome

1. Open a new Incognito window (Cmd/Ctrl+Shift+N) and navigate to the site.
2. Open DevTools (F12 or Cmd/Ctrl+Shift+I) before or immediately after the page loads.
3. Go to the Application tab, then Storage → Cookies in the left sidebar, and pick the site's origin. This lists every cookie already set: its name, domain, expiry and flags (Secure, HttpOnly, SameSite).
4. Switch to the Network tab, reload the page (Cmd/Ctrl+R) with the panel already open, and filter by Domain. Any request to a domain that isn't the site itself is a third-party connection — that's where most tracking happens, cookie or not, since a page can also identify you through the request itself (see first-party versus third-party cookies).
5. Sort the Network panel's requests by time. Anything that fired within the first second or two, before you could plausibly have reacted to a banner, is a good candidate for "loaded before consent."

Chrome also has a dedicated Privacy and security → Third-party cookies view and a cookie icon in the address bar showing a live count, but the Application tab gives the full detail: name, value length, domain and expiry.

While you're in the Application/Storage tab, it's worth glancing at each cookie's flags, since they say something about intent too: Secure means it's only ever sent over HTTPS, HttpOnly means client-side JavaScript can't read its value (a security measure, common for session tokens), and SameSite controls whether it's sent along with requests that originate from another site — Strict or Lax limits that, while None (paired with Secure) is what a cookie needs if it's meant to work across sites, which is exactly the setting most third-party advertising cookies use.

Firefox

1. Open a new Private Window (Cmd/Ctrl+Shift+P) and navigate to the site.
2. Open DevTools (F12), go to the Storage tab, and expand Cookies for the site's origin. Same information as Chrome: name, value, domain, expiry, flags.
3. The Network tab works the same way — reload with it open, and look at the Domain column to spot third-party requests.
4. Firefox's Enhanced Tracking Protection (the shield icon in the address bar) shows what it already blocked, but a site can still set cookies through connections ETP allows, so check Storage directly rather than trusting the shield alone.

What to look for

• Timing. A cookie or request present on the very first load, with no banner interaction, is one the site set unconditionally. That's the practical test used by regulators and by scans like ours: did anything non-essential load before a choice was made?
• Category. A cookie named _ga or a request to googletagmanager.com is analytics; one to doubleclick.net is advertising; one to facebook.net or linkedin.com is social. What the tracker categories mean has the fuller breakdown, matching how this site classifies companies.
• Lifetime. A cookie's Expires field tells you how long it persists. Session cookies (no expiry shown, or "Session") disappear when you close the browser; others are set for months or years. See how cookie lifetimes work.

The limits of checking it yourself

A single manual check is a snapshot, and it has real limitations worth knowing about before you draw conclusions from it:

• Geography matters. A site can (and legally, often should) behave differently depending on where the visitor appears to be. A check from the US may show trackers that the same site holds back for an EU visitor, or vice versa.
• It varies by run. A/B tests, ad auctions and randomized tag firing mean the exact set of requests can differ between visits.
• Server-side setting is invisible in Network alone. Some cookies are set by the site's own backend in an HTTP response header rather than by client-side JavaScript, which changes how they show up but not whether they're tracking you — more on that distinction in the first-party vs third-party guide.
• One page isn't the whole site. A homepage can be clean while an article page or checkout flow loads a different set of tags entirely.

How CookieTosser does it at scale

Manually checking one site is useful when you want to verify something specific. Checking thousands of sites the same way, every month, is what this site automates: each scan loads a site's homepage in a fresh browser profile, from a server in Germany, waits for the network to go quiet, and records every cookie and outside host contacted — without ever clicking the consent banner. That's the same "before consent" test described above, just run at scale and kept consistent from one month to the next.

You can look up any of the 2,450 sites we've scanned on its own site report, browse every company we've identified, or check what a specific cookie is for in the cookie dictionary. If a site's report looks out of date, ask for a rescan.