What Are Third-Party Cookies? A Site Owner's Plain-English Guide

So what are third party cookies, really? Here's the fast version: a browser decides whether a cookie is "first-party" or "third-party" by looking at one thing, the domain in your address bar versus the domain that set the cookie. If they match, it's first-party. If they don't, it's third-party, and depending on which browser your visitor uses, that cookie either travels freely, gets blocked outright, or gets locked into its own isolated jar.

This one distinction quietly decides whether your login widget works, whether your ad network can measure anything, and whether that cookie banner on your homepage is doing real work or just annoying people for nothing.

Two different readers land on this page. One is a visitor who saw "block third-party cookies" in a browser settings menu and wants to know if flipping it is a good idea. The other runs a website and just realized their analytics script, their embedded map, or their affiliate tracking pixel might be one of the third-party cookies everyone keeps talking about. Both questions get answered here, because they're really the same question asked from opposite sides of the same request.

First-Party vs Third-Party Cookies: What Actually Sets Them Apart

A cookie is a small piece of text a server asks your browser to store, then sends back on future requests to that same server. That's the whole mechanism. Login sessions, shopping carts, language preferences, all of it runs on this one idea. The first-party versus third-party split doesn't change how a cookie works, it changes who can read it and when.

Per MDN's documentation on third-party cookies, a cookie is first-party "if the cookie domain and scheme match the current page the user is looking at." Anything else counts as third-party, even, and this trips people up constantly, if the third-party domain belongs to the exact same company.

Google's own example makes this concrete: a site called cats.example embeds a map from catmap.example, an ad from adtech.example, and an analytics script from analytics.example. Even a widget from cat-hire.example, owned by the same business as cats.example, still counts as third-party because the domain is different. Ownership doesn't matter to the browser. The domain in the address bar is the only thing it checks.

MDN actually argues the label "third-party cookie" is a bit misleading, since it implies another company owns the data. The more accurate term, gaining ground in technical writing, is "cross-site cookie." I'll use both here because "third-party" is what people search for, but keep the cross-site framing in your head, since it matches what the browser is checking.

Here's the comparison laid out plainly:

One flag worth knowing by name: a cookie can't even attempt to travel cross-site unless it carries SameSite=None; Secure. MDN's example looks like Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly. The Secure part means the cookie only travels over HTTPS, so a site that hasn't forced HTTPS on every page (ideally backed by an HSTS header) loses it on plain-HTTP requests. Without that pairing, browsers quietly drop the cookie in cross-site contexts before third-party rules even come into play. That single response header attribute is doing more gatekeeping than most site owners realize, and it's worth understanding alongside the rest of what a server sends back; httpcheck.tools has a plain guide to what each response header does.

What third-party cookies are actually used for

Not every third-party cookie exists to track you across the web. MDN lists several legitimate uses that have nothing to do with surveillance advertising: affiliate tracking, cross-site sign-in widgets, sharing preferences across a family of related sites, cross-site analytics for companies running multiple properties, and ad impression counting. That embedded YouTube player on a blog post, the "Login with Google" button, the support chat widget that follows a visitor from your homepage to your pricing page, all commonly rely on a third-party cookie doing something reasonable.

Then there's the use case that gives the whole category its bad reputation: building a profile of someone's browsing across unrelated sites, usually for ad targeting. That's a real thing third-party cookies enable, and it's the reason regulators and browser vendors care. But not every third-party cookie tracks a person across sites, and not every tracking cookie is third-party (plenty of sites run first-party analytics that build a detailed profile too). What matters more than the label is what a specific cookie actually does, and whether your consent setup treats it accordingly.

Does Chrome block third-party cookies?

Short answer: no, not by default, and this is the single most outdated piece of information floating around the web right now. For years, "Chrome is phasing out third-party cookies" was accurate advice to give. It stopped being accurate on 22 April 2025.

Here's the actual timeline. Google announced its intent to deprecate third-party cookies back in 2019, then pushed the deadline repeatedly through 2021 and 2023 as its Privacy Sandbox replacements struggled to get traction. On 22 April 2025, Google published a post titled "Next steps for Privacy Sandbox" stating that it had "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome." Read that carefully: not a delay, a reversal.

Six months later, on 17 October 2025, Google retired most of the Privacy Sandbox APIs it had built for the cookieless future, including Attribution Reporting, Topics, and Protected Audience, citing "low levels of adoption." A handful of pieces survived, including CHIPS (partitioned cookies) and FedCM, both of which we'll get to. For the primary source, Google's own April 2025 announcement is worth reading in full.

So what does Chrome actually do today? Per MDN, "Google Chrome doesn't block third-party cookies by default, only in Incognito mode, or when users explicitly set it to block third-party cookies via chrome://settings." In a normal Chrome window, a third-party cookie with the right flags travels just fine unless the person using the browser changed the setting themselves.

What each browser does today

Chrome isn't the whole story, and treating it as the default assumption for how the web behaves is where a lot of outdated advice comes from. Here's where the major browsers actually stand:

Safari was first to move. Apple's WebKit team wrote in a March 2020 post that "cookies for cross-site resources are now blocked by default across the board," calling Safari "the first mainstream browser to fully block third-party cookies by default." You can read the full announcement on the WebKit blog. Embeds that genuinely need cross-site state have to ask the user through the Storage Access API instead.

Firefox took a different route with what it calls Total Cookie Protection, rolled out to everyone worldwide on 14 June 2022. Mozilla's own description: "Total Cookie Protection works by creating a separate 'cookie jar' for each website you visit," which it called "Firefox's strongest privacy protection to date" in its announcement post. The important nuance: Firefox doesn't refuse the cookie the way Safari does. It isolates it per top-level site, so the embed still technically works, it just can't recognize the same visitor across two different sites anymore.

Edge sits in the middle with three tiers, Basic, Balanced (the default), and Strict. According to Microsoft's own tracking prevention documentation, Balanced mode blocks storage access for trackers classified as Advertising, Content, Social, and Other, using Disconnect's tracker lists, but leaves Analytics trackers alone until you switch to Strict. So Edge doesn't block all third-party cookies by default, it blocks a curated list of known trackers. That's a meaningfully different mechanism from Safari's blanket block.

Should you block third-party cookies?

This question genuinely has two different correct answers depending on who's asking.

As a visitor deciding a browser setting: yes, turning it on costs you very little, and if you're on Chrome or Edge (where the toggle actually matters, since Safari and Firefox have already made most of this decision for you) it's a reasonable default to flip. The tradeoff is that some sites break in small ways: a shared login won't carry over between two sites owned by the same company, an embedded comment widget might show you as logged out, a payment iframe might silently fail to load your saved details. None of that is catastrophic, and most sites have moved their essential embeds onto mechanisms that survive blocking, like CHIPS.

As a site owner: the honest answer is that you can't block or allow third-party cookies for your visitors. That decision lives in their browser, not your server. What you can and should do is know exactly which third-party cookies your own site is handing out, whether they're gated behind a consent banner, and what breaks for the roughly 15% of visitors on Safari who never send those cookies at all. Run your own site through a checker like the one at cookiecheck.tools and you'll usually find at least one third-party cookie you didn't know was there, often from an ad script a marketing tool added months ago.

What breaks when they're blocked

The forum posts on this topic have a consistent shape: someone blocks third-party cookies, then can't log into an embedded app, or a payment iframe stops working, or a school portal or banking widget shows them logged out. That pattern shows up across Adobe's developer community, Shopify's merchant forums, and Spotify's support threads. It's rarely someone objecting to being tracked. It's someone trying to get a form to submit.

A 2024 measurement study out of IIT Gandhinagar, published as a preprint on arXiv, gives some texture to how common this is. The researchers instrumented Firefox and crawled the top 10,000 sites by traffic (the Tranco list), finding that third-party scripts were involved in 89.84% of all cookie accesses they observed, and that roughly 45% of cookies created by the host site itself were later read by third-party scripts.

When they tested default third-party cookie blocking against 100 real sites, it disrupted analytics libraries on 40 of them, ad delivery on 17, reCAPTCHA on 10, and cookie consent banners themselves on 11. You can read the full preprint on arXiv, with the caveat that it hasn't gone through formal peer review yet, but the numbers line up with what site owners report anecdotally.

The fix that's gaining traction for embeds that genuinely need cross-site state (chat widgets, video players, some CDN-backed session tools) is CHIPS: cookies that add a Partitioned attribute and opt into their own isolated jar per top-level site, deliberately, rather than getting blocked by browser policy. It's one of the few Privacy Sandbox pieces Google kept in October 2025, alongside FedCM. If you're building an embed today, that's the direction to design toward.

How do I see which third-party cookies a site sets?

Two ways, and they answer slightly different questions.

In your own browser, Chrome DevTools has an Application tab with a Cookies panel under Storage. It shows every cookie's domain, its SameSite value, and a Partition Key column for CHIPS cookies. Filtering to "only show cookies with an issue" narrows it down fast when you're troubleshooting a specific site.

For a fuller picture without opening DevTools on every page, a URL checker like cookiecheck.tools fetches a page once, reads every Set-Cookie header, and groups the third-party hosts it finds by category (advertising, analytics, social widgets, session replay), flagging whether a consent banner is actually gating them before they fire. Worth being upfront about the limit: a single server fetch can't see cookies written by JavaScript after the page loads, or tags injected through a tag manager. That's why a second check against your own browser's storage is the honest complement to a server-side scan. You can see what each part of the score grades, and where the method's blind spots are, on the about page.

Third-party cookies aren't disappearing the way headlines from a few years ago promised, and they aren't universally blocked either. The real answer depends on which browser is asking and what that specific cookie is actually doing. If you run a site, the useful move isn't guessing, it's checking. Run your URL through cookiecheck.tools and see exactly which third-party hosts your page hands cookies to, and whether your consent setup actually covers them.

Frequently Asked Questions

What is the difference between first party and third party cookies?

A first-party cookie is set by the same domain shown in your browser's address bar. A third-party cookie is set by any other domain embedded on that page, an ad network, an analytics script, a widget, even if that domain belongs to the same company running the site. The browser only checks the domain match, not who owns it, which is why MDN prefers the more accurate term "cross-site cookie."

Should I block third-party cookies?

As a visitor, blocking them is a reasonable default with a small tradeoff: a handful of embedded logins, shared sessions, or payment widgets may stop recognizing you across sites. Safari and Brave already block them for you by default, and Firefox isolates them, so the setting mostly matters on Chrome and Edge. As a site owner, you can't control this setting for your visitors either way; what you can do is audit which third-party cookies your own site sets and whether a consent banner gates them properly.

Does Chrome block third-party cookies?

Not by default, as of 2026. Chrome blocks them automatically only in Incognito mode. In a regular window, third-party cookies are allowed unless the person using the browser manually turns them off in Settings > Privacy and security > Third-party cookies. Google confirmed it would keep this approach, rather than removing third-party cookies entirely, in an April 2025 announcement.

How do I see which third-party cookies a site sets?

Open Chrome DevTools, go to the Application tab, then Storage, then Cookies, and look at the domain and SameSite columns for entries that don't match the site you're on. For a faster overview without digging through DevTools, run the URL through a checker that groups third-party hosts by category and flags trackers firing before consent, keeping in mind that a server-side scan won't catch cookies set purely by JavaScript after the page loads.