What Is a Third-Party Cookie? The Types of Cookies Explained

What is a third-party cookie? It's a small text file set by a domain other than the website you're actually visiting — usually an advertiser, analytics provider or social widget — so that company can recognize you as you move from site to site. That single distinction, first-party versus third-party, is the most important thing to understand about cookies, because it drives almost everything else: whether a cookie helps a site work or tracks you across the web, whether a browser blocks it by default, and whether it lands you in a consent-law problem.

This guide is the taxonomy — every type of cookie that matters, sorted the way the law and your consent banner actually sort them. If you just want a plain-English primer on what cookies are and how to clear them in your browser, start with what cookies are, in plain English and come back here when you want the full map. We'll cover first-party vs third-party, the four consent categories (strictly necessary, functional, analytics and targeting), the short-lived versus long-lived split, and the weird ones most articles skip — super cookies, flash cookies, zombie cookies and the cookie security flags developers actually set. And because 2025 rewrote the headline everyone remembers, we'll clear up what really happened to third-party cookie deprecation.

Cookies, in one paragraph

A cookie is a small piece of data a website asks your browser to store, then hands back on your next request so the site can "remember" something — that you're logged in, what's in your cart, which language you picked. Technically these are HTTP cookies (the "what are HTTP cookies" question is just this: cookies delivered over the web's HTTP protocol via a Set-Cookie header). On their own, cookies are neutral plumbing. What makes one type of cookie helpful and another invasive isn't the file format — it's who sets it, how long it lives, and what it's used for. Those three questions are exactly how we'll classify them.

First-party vs third-party cookies

The single most useful way to classify a cookie is by origin: which domain set it, relative to the site showing in your address bar.

What is a first-party cookie?

A first-party cookie is set by the domain you're actually visiting. If you're on yourshop.com and yourshop.com stores a cookie, that's first-party. These are the cookies that keep you logged in, hold your cart, remember your currency and let the site function. Because they belong to the site you chose to visit, browsers treat them as trusted and rarely block them.

What is a third-party cookie?

A third-party cookie is set by a different domain than the one in your address bar — loaded through some element the page embeds, like an ad, a "Like" button, an embedded video or an analytics tag. On yourshop.com, a cookie set by doubleclick.net or facebook.com is third-party. Because that same third party's code is embedded on thousands of other sites, its cookie can recognize you everywhere it appears — which is precisely how cross-site tracking and retargeting ads work. This is what people mean by "tracking cookies," and it's why third-party cookies attract nearly all the privacy scrutiny.

A third-party cookie example, step by step

The mechanics are easier to see with a concrete third-party cookie example. Say you visit an online shoe store:

This is why "should I block third-party cookies?" is a reasonable question for an individual browsing the web, and why regulators treat these cross-site cookies as personal data requiring consent. It's also why every mainstream browser except Chrome now blocks them by default — more on that under deprecation.

The four consent categories

Origin tells you who set a cookie. But your cookie banner doesn't ask visitors about domains — it asks them about purpose. Nearly every consent management platform sorts cookies (first- and third-party alike) into the same four buckets, which come straight from the way EU guidance and the major CMPs standardized them. Knowing these four is the practical core of cookie compliance.

What are strictly necessary (essential) cookies?

Strictly necessary cookies are the ones a site genuinely can't work without — keeping you signed in, holding items in your basket through checkout, balancing server load, blocking fraud. Because the visitor asked for the service that requires them, most consent regimes treat them as exempt: you don't need opt-in to set them (though you should still disclose them). The catch is that "necessary" is frequently abused as a dumping ground. Analytics and marketing cookies are not necessary, no matter how useful they are to you.

What are functional cookies?

Functional cookies remember choices that improve the experience but aren't essential — your language, your last-viewed store, whether you dismissed a banner, chat-widget state. They usually require consent because the site works fine without them.

What are analytics (performance) cookies?

Analytics cookies — also called performance cookies — measure how visitors use a site: which pages they see, how long they stay, where they drop off. Google Analytics is the classic example. These feel harmless to site owners, but they process behavioral data and, in most jurisdictions with a cookie-consent regime, require opt-in before they run. In US wiretap litigation, analytics and session-replay scripts firing before consent are a central allegation — so "it's just analytics" is not the safe harbor many assume.

What are targeting (advertising) cookies?

Targeting cookies — the advertising category — are the most sensitive. They build profiles across sites to serve personalized ads and measure campaigns; the Meta Pixel, Google Ads and most ad-network cookies live here, and they're overwhelmingly third-party. These always require consent, and they're the category most likely to draw a complaint when they fire early.

Session vs persistent cookies

The third axis is lifespan. A session cookie lives only while your browser session is open and is deleted the moment you close the tab or browser — it has no expiry date, so it's held in memory. A staff login token or a "you have items in your cart" flag is typically a session cookie. A persistent cookie carries an explicit expiry (a day, a month, two years) and survives restarts, which is how a site remembers you weeks later. "Remember me," long-lived analytics IDs and advertising cookies are usually persistent.

That's the essential distinction; because it deserves its own worked examples — including how expiry dates and the affiliate-marketing "cookie duration" concept work — we cover it in depth in session cookies vs persistent cookies. For classification here, just remember: lifespan is independent of origin and purpose. A cookie can be first-party and analytics and persistent all at once.

Super, flash, zombie & other exotic cookies

Beyond the everyday cookie types, a handful of "exotic" tracking mechanisms exist specifically to be harder to delete or to identify you when ordinary cookies can't. Most guides skip these; they matter because they're the reason "just clear your cookies" isn't the whole answer.

Cookie security flags: HttpOnly, Secure & SameSite

When developers ask "what is an HttpOnly cookie" or "what is a secure cookie," they're really asking about attributes a cookie can carry. These aren't separate types so much as safety settings that decide how a cookie behaves — and they're what protects a session cookie from the cookie logger above.

If you run a site, the short version: session and login cookies should be HttpOnly and Secure, and you should understand your SameSite settings, because SameSite=None is what lets a cookie act in a third-party, cross-site context in the first place.

The deprecation myth: what really happened in 2025

For years the headline was "third-party cookies are going away." Google announced it would phase out third-party cookies in Chrome; the whole ad industry braced for a cookieless future. Then the story reversed — and a lot of published guides never updated. Here's the current, accurate picture.

What actually changed

In April 2025, Google announced it would not roll out a standalone prompt to turn off third-party cookies in Chrome; the cookies stay, and by late 2025 Google began winding down parts of its Privacy Sandbox cookie-replacement effort. So in Chrome — still the majority browser — third-party cookies are not blocked by default in 2026.

But that's only Chrome. Safari has blocked third-party cookies by default since 2020 (via Intelligent Tracking Prevention), Firefox blocks and partitions them by default (Total Cookie Protection), and Brave blocks them outright. Together those browsers are a large minority of traffic — which is why, in practice, roughly a third of your visitors already arrive with third-party cookies blocked, regardless of what Chrome did.

Why deprecation never reduced your consent duties

Here's the part that matters for anyone running a website. Consent law is technology-neutral. Europe's ePrivacy rule governs storing or accessing any information on a user's device — cookie or not. California's CCPA and its wiretap statute, and the growing list of US state privacy laws, regulate the collection and sharing of personal information and the interception of communications — again, regardless of mechanism. First-party analytics, server-side tracking, pixels and fingerprinting all fall inside these rules. So even in a world with zero third-party cookies, you would still need consent before analytics and marketing trackers run. The cookie was never the legal trigger; the tracking is.

Should you block third-party cookies on your own site?

Most guides answer "should I block third-party cookies?" from the browsing visitor's chair (yes, for privacy — and the browser guide shows how). The more important question, if you run a website, is different: which cookies and trackers should you let fire, and when?

The site-owner rule of thumb

Are third-party cookies bad? Is it safe to allow them?

For a visitor, third-party cookies aren't malware — but they're the main engine of cross-site tracking, which is why privacy-minded users and most browsers block them. For a site owner, the risk isn't the cookie itself; it's letting analytics, advertising or session-replay tools run before consent. In the US, that's the exact pattern plaintiffs target under the California Invasion of Privacy Act, where the wiretap provisions carry statutory damages of $5,000 per violation under Cal. Penal Code §637.2. "Are third-party cookies safe?" is the wrong question for a business. "Is anything tracking my visitors before they agreed?" is the right one — and it applies to first-party tools too.

This is where a prevention-first approach differs from a typical banner. ConsentPixel is built to block analytics, advertising and session-replay trackers — first- and third-party — from firing until a visitor genuinely consents, then release them and log the decision. It's the difference between asking for permission and actually withholding the data until you have it. You can see the current state of your own site with the privacy scanner, and read the litigation backdrop in the CIPA overview and the CIPA lawsuit tracker.

Frequently asked questions

A plain-English guide, not legal advice. Cookie and privacy rules — including CIPA, CCPA, GDPR and ePrivacy — vary by jurisdiction and change frequently. The $5,000 figure refers to statutory damages available under California Penal Code §637.2 and is included for context, not as a prediction about any specific site. Confirm your obligations with a qualified professional.