First-party cookies are set by the site you are visiting and stay on that site. Third-party cookies are set by a different domain's embedded code and can follow you across every site that loads the same code. The difference is origin: who dropped the cookie, not who owns the data.
This guide covers what each type does and how browsers classify them. It also covers which browsers block them by default, what each type requires for consent, and how to manage both. The browser answer is not what the AI Overviews claim.
First-Party vs Third-Party Cookies: The Short Answer
The single dividing line is the origin domain. A cookie is first-party when the domain that set it matches the domain in your browser's address bar. A cookie is third-party when the domain is different.
First-party cookies power the single site you are on: your login session, your shopping cart, your language preference. Third-party cookies power cross-site tracking. An ad network sets one cookie and reads it on every other site that runs the same ad script. That builds a behavioral profile across your browsing.
Before going deeper, it helps to know what a cookie is at all. Cookies are also one of several ways to group trackers: first- vs third-party is just one axis. See the full range of cookie types for the complete taxonomy.
What Are First-Party Cookies?
A first-party cookie is set by, and readable only by, the domain shown in the browser's address bar. When you visit shop.example.com, any cookie with the domain shop.example.com is first-party. It belongs to that site, and only that site can read it.
How First-Party Cookies Are Set
The site's own server sets a first-party cookie by including a Set-Cookie header in its HTTP response, scoped to the site's domain. The site's own JavaScript can also write a cookie via document.cookie. Either way, the cookie domain matches the address-bar URL: that match is what makes it first-party. Source: MDN Web Docs, last modified 2026-06-15. Confidence: HIGH.
What First-Party Cookies Are Used For
First-party cookies handle single-site functionality.
- Session management (keeping you logged in)
- Shopping cart persistence across pages
- Language and theme preferences
- On-site personalization (recently viewed items)
- First-party analytics (visit counts, page paths, session duration)
Examples of First-Party Cookies
Named, specific examples from the most common tools follow.
session_idorPHPSESSID: the login session cookie set by your server, readable only on your domain.cart_items: stores a visitor's cart contents; scoped to the shop domain.language: stores the chosen display language; set by the site's own JavaScript._ga(Google Analytics 4): set on your domain by GA's JavaScript; technically first-party because the domain matches your site. The data, however, is sent to Google. First-party is a technical label, not a privacy guarantee. The FAQ section below and the myth-buster section below cover this important nuance.
The Limits of First-Party Cookies
First-party cookies have specific constraints.
- Single-site scope only. A first-party cookie cannot see or read anything from another domain. It is invisible outside its origin.
- Safari ITP caps JavaScript-set cookie lifespan. Safari's Intelligent Tracking Prevention (ITP) limits cookies set via JavaScript (not
Set-Cookieheaders) to 7 days. If your analytics depends on JS-set cookies, return visits beyond one week appear as new sessions in Safari. - First-party cookies can still feed third parties. Server-side tagging, CNAME cloaking, and tools like GA4 use first-party storage while sending data out. "First-party" describes who set the cookie, not where the data goes.
- Not exempt from consent when used for analytics. In the EU and UK, first-party analytics cookies that identify users still require consent. "First-party" does not mean "consent-free." See how long cookies last for the duration dimension.
What Are Third-Party Cookies?
A third-party cookie is set by a domain different from the one in the browser's address bar. It arrives via embedded content: an ad script, a tracking pixel, a social share button, or an iframe loaded from another domain. The cookie's domain is the third party's domain, not yours.
That third party can read its cookie on every site that loads its code. A user visits site A, the ad network sets a cookie. The user visits site B, which loads the same ad network script. The ad network sees its cookie and knows the user was also on site A. That is cross-site tracking in practice.
Source: Google Privacy Sandbox, last updated 2025-12-18. Confidence: HIGH.
How Third-Party Cookies Are Set
A browser loads your page. Your page includes a resource from another domain: an ad, a pixel, a widget, or an iframe. That external domain's server responds and includes a Set-Cookie header scoped to its own domain. For that cookie to follow the user across sites, the server must set SameSite=None; Secure. Without both attributes, modern browsers (using SameSite=Lax as the default) will block the cookie on cross-site requests.
Source: MDN Web Docs (F-18, F-19). Confidence: HIGH.
What Third-Party Cookies Are Used For
Third-party cookies enable cross-site data collection.
- Cross-site retargeting (showing ads for products you viewed elsewhere)
- Ad serving and frequency capping (limiting how often you see the same ad)
- Conversion attribution (crediting which site or ad led to a purchase)
- Cross-site audience and behavioral profiling
- Cross-site analytics and measurement dashboards
Examples of Third-Party Cookies
Concrete named examples follow.
- Google Ads / DoubleClick cookie: set by
ad.doubleclick.netembedded on millions of sites; tracks ad exposure and conversions across the web. - Meta Pixel cookie: set by
connect.facebook.netscripts embedded on e-commerce and publisher sites; powers Facebook retargeting. - YouTube embed cookie: loading a YouTube iframe sets cookies from
youtube.com; these are third-party to your domain. - Social share widget: a "Tweet this" button loading a script from
twitter.comcan set third-party cookies on your page.
These are exactly the cookies Consently's scanner flags and auto-blocks until the user consents.
The Limits of Third-Party Cookies
Third-party cookies face significant constraints.
- Blocked by default in Safari and Firefox. Safari's ITP and Firefox's Enhanced Tracking Protection (ETP) block third-party cookies from known trackers by default. Safari is the dominant browser on iPhone.
- Restricted in Edge and Brave. Edge's Balanced mode (default) blocks trackers from unvisited sites. Brave blocks all third-party cookies by default.
- Chrome does not block by default, but user controls apply. Chrome requires explicit opt-in to block them. See the phase-out section below for the current status.
- Require
SameSite=None; Secureto function. Without these attributes, third-party cookies fail silently in modern browsers. - Require explicit prior consent under GDPR. Third-party advertising and tracking cookies are non-essential. They need opt-in consent before loading in EU and UK contexts.
First-Party vs Third-Party Cookies: Side-by-Side Comparison
Here is how the two compare on the dimensions that matter.
| Dimension | First-Party Cookie | Third-Party Cookie |
|---|---|---|
| Who sets it | The site in the address bar | A different domain via embedded code |
| Which domains can read it | Only the originating domain | The third party, on every site running its code |
| Tracking scope | Single-site only | Cross-site (tracks users across multiple sites) |
| Primary purpose | Logins, carts, preferences, first-party analytics | Retargeting, ad serving, attribution, behavioral profiling |
| Privacy impact | Lower (single site) | Higher (builds cross-site behavioral profile) |
| Needs consent? (EU/UK) | Strictly necessary: no; analytics: generally yes | Advertising/tracking: always requires explicit consent |
| Browser treatment in 2026 | Supported and trusted by all browsers | Blocked by default in Safari and Firefox; available in Chrome (user controls apply) |
| Typical lifespan | Longer; browsers trust them (note: Safari caps JS-set cookies at 7 days) | Shorter or zero; blocked, capped, or deleted by anti-tracking |
| Future outlook | The strategic direction; here to stay | Declining; already blocked in Safari/Firefox; Chrome reversed its blanket-removal plan |
Browser support and the phase-out status are the sharpest divergence in 2026. Consult cookie categories for the purpose dimension (essential, analytics, advertising).
How Does a Browser Decide Which Is Which?
A browser classifies a cookie as first- or third-party by matching the cookie's domain and scheme against the URL in the address bar. If both the domain and the scheme (http or https) match the address-bar URL, the cookie is first-party. If either differs, it is third-party. Source: MDN Web Docs. Confidence: HIGH.
The SameSite attribute controls cross-site delivery. Modern browsers default to SameSite=Lax when no attribute is set. The three values determine when the cookie is sent:
SameSite=Strict: the browser sends the cookie only in same-site contexts.SameSite=Lax(the default): the browser sends the cookie in same-site requests and in top-level GET navigations (clicking a link to the site). Not sent in cross-site subrequests.SameSite=None: the browser sends the cookie in both same-site and cross-site contexts. TheSecureattribute is also required; without it, the cookie is blocked.
Third-party cookies require SameSite=None; Secure to function in cross-site contexts. This is why many third-party cookies broke silently when Chromium adopted the Lax default: the cookies lacked the required attributes.
How to Tell If a Cookie Is First-Party or Third-Party
Open your browser's developer tools and check the Domain column for any cookie. The steps are below.
- Open your browser and visit the site you want to inspect.
- Press F12 (or right-click the page and choose "Inspect").
- Go to the Application tab (Chrome/Edge) or Storage tab (Firefox).
- Select Cookies in the left-hand panel, then choose the site's URL.
- Look at the Domain column for each cookie.
- If the domain matches the address-bar domain, the cookie is first-party. If it differs, it is third-party.
You can also check your browser's privacy or site-settings panel to see which third-party cookies a site attempted to set and whether they were blocked.
Do First-Party and Third-Party Cookies Need Consent?
Consent depends on purpose and jurisdiction, not on the first- or third-party label alone. A strictly necessary cookie is exempt from consent whether it is first- or third-party. An analytics cookie needs consent in the EU even if it is first-party.
The rule is purpose and law. Whether a cookie needs cookie consent depends on what it does, not who set it.
Here is how the main frameworks treat each cookie type.
| Cookie type | Consent under GDPR/ePrivacy (EU/UK) | Treatment under CCPA/CPRA (US) |
|---|---|---|
| Strictly necessary (first- or third-party) | No consent required; exempt | Not a "sale"; no opt-out required |
First-party analytics (e.g., GA4 _ga) | Consent generally required; narrow anonymous-analytics exemptions exist | Opt-out right applies if data is sold or shared with analytics vendors |
| Third-party advertising/tracking | Explicit prior opt-in consent always required | Opt-out right applies ("Do Not Sell or Share My Personal Information") |
Source: GDPR.eu (F-14, F-15, F-16). Confidence: HIGH for EU/UK rules; MEDIUM for CCPA specifics.
The GDPR applies to cookies "insofar as they are used to identify users." Source: GDPR.eu. A first-party analytics cookie that identifies a returning visitor is personal data under this test. Being first-party does not exempt it.
Are Third-Party Cookies Going Away? The Phase-Out, Explained
The short answer: Safari and Firefox have already eliminated third-party cookie tracking by default. Chrome has not, and its blanket-removal plan was reversed.
Here is the accurate 2026 picture, correcting a widespread misconception in AI Overviews.
Safari blocks third-party cookies by default via ITP, active since 2017. Firefox blocks known trackers by default via Enhanced Tracking Protection (ETP); Strict mode blocks all third-party cookies. Chrome does not block third-party cookies by default. Users must opt in via Settings > Privacy and Security > Third-party cookies. Chrome Incognito mode does block them.
On July 22, 2024, Google reversed its plan to blanket-remove third-party cookies from Chrome. Instead of a mandatory phase-out, Google moved to a "user choice" model. On April 22, 2025, Google confirmed it would not introduce a separate consent prompt for third-party cookies. Users manage cookie access via existing Chrome privacy settings.
Google's Privacy Sandbox status page, last updated December 11, 2025, is explicit. It states: "Third-party cookie restrictions: third-party cookies are available." Source: Google Privacy Sandbox status page, corroborated by JENTIS (published 2026-01-13) and Usercentrics. Confidence: HIGH, 4 independent sources.
Third-party cookies remain unreliable for measurement because Safari and Firefox block them by default. Those browsers cover a significant share of mobile traffic. The third-party cookie phase-out page covers the full timeline. Sites shifting away are moving to cookieless tracking and first-party approaches.
First-Party Cookies Are Not Automatically "Private"
"First-party" tells you who set the cookie, not where the data goes. This distinction matters more than the label suggests.
A first-party cookie can still send data to a third party.
- Server-side tagging: your server receives user data and forwards it to an analytics or ad vendor. The cookie stays on your domain, but the vendor receives the same information it would have via its own third-party cookie.
- CNAME cloaking: a CNAME record points
tracking.yoursite.comto a third-party tracker's servers. The browser sees your domain and treats the cookie as first-party. Safari and Firefox detect and restrict CNAME cloaking. Chrome does not. - GA4's
_gacookie: Google Analytics sets_gaon your domain, making it technically first-party. The session and behavior data is sent to Google's servers. "First-party storage" and "first-party data controller" are not the same thing.
The label is the browser's view. It says nothing about the data's destination. For cross-site tracking mechanics, see the cross-site tracking guide linked in the comparison section above.
Do not confuse first-party cookies with first-party data, which is the information you own and collect directly from your audience. First-party data is the broader category; a first-party cookie is one storage mechanism for collecting it.
What About Second-Party Cookies?
"Second-party cookies" is not a real technical classification. Cookies are only ever first-party (the domain matches the address bar) or third-party (it does not). The term borrows loosely from "second-party data," which is another company's first-party data shared with you by a direct agreement. No browser recognizes a "second-party" cookie class. When you see the term, it refers to a data-sharing concept, not a cookie origin category.
When Should You Use First-Party vs Third-Party Cookies?
These are not products to choose between: they are technical classifications that follow from how your site is built. The decision is not which type to "use" but which to keep, restrict, or gate behind consent. The answer depends on purpose, law, and browser support.
Use first-party cookies when you need functionality that stays on your site.
- Logins, session state, and shopping carts require first-party cookies. There is no cross-site replacement.
- First-party analytics (GA4 in first-party mode, Plausible, Fathom) gives you owned data that browsers do not block.
- Preference and personalization cookies (language, theme) are low-risk when truly non-tracking.
- Safari's ITP caps JavaScript-set first-party cookies at 7 days. Server-set cookies via
Set-Cookieare more durable for returning-visitor analytics.
Restrict or plan to replace third-party cookies when they serve cross-site advertising or tracking.
- Safari and Firefox already block them by default, covering the majority of mobile browsing on iPhone.
- Chrome's user-choice model and technical restrictions (SameSite requirements) make third-party measurement unreliable.
- Privacy Sandbox APIs (CHIPS, Storage Access API) provide scoped alternatives for specific embedded-widget use cases.
- Plan for first-party data collection and Privacy Sandbox alternatives for advertising attribution.
Use consent controls when any cookie is non-essential under the applicable law.
- Gate first-party analytics cookies behind opt-in consent for EU and UK visitors. Being first-party does not create an exemption.
- Gate all third-party advertising and tracking cookies behind explicit prior consent, wherever GDPR or ePrivacy applies.
- Honor opt-out signals (Global Privacy Control, "Do Not Sell or Share") under CCPA/CPRA for any third-party data sharing.
- Purpose and jurisdiction decide consent, not the first- vs third-party label.
How Consently Handles First-Party and Third-Party Cookies
Consently is a consent management platform that scans, categorizes, and blocks cookies on your site, then records the user's consent choice. It does not change whether a cookie is first- or third-party. It governs what happens to each type before and after the user decides.
Detecting and Managing First-Party Cookies
Consently's full-site scanner detects first-party cookies set by your own domain. This includes analytics cookies like GA4's _ga, session cookies, and preference cookies. The scanner categorizes each cookie as essential, analytics, performance, or another category. Strictly necessary cookies pass through without consent. First-party analytics cookies are flagged, and Consently's preference center lets users accept or reject them independently. If a visitor declines, Consently's script blocking prevents those scripts from running.
Detecting and Blocking Third-Party Cookies
Consently detects third-party cookies, trackers, scripts, and iframes. For any third-party script or iframe that is non-essential, Consently's auto-blocker prevents it from loading until the user gives consent. Blocked iframes display an editable placeholder so embedded content does not leave blank holes. Once the user consents, the blocked scripts and iframes load normally. For ad-tech consent, Consently supports Google Consent Mode v2, passing consent signals to GA4 and Google Ads. It also supports IAB TCF, passing those signals to the broader ad-tech ecosystem.
Start a free trial and scan your site for first- and third-party cookies: Try Consently free.
FAQs
What is the main difference between first-party and third-party cookies?
First-party cookies are set by the site you are visiting and stay on that domain. Third-party cookies are set by a different domain whose code is embedded on the page. They can track you across every site that loads the same code. The dividing line is origin: does the cookie's domain match the address bar?
How do I tell if a cookie is first-party or third-party?
Open DevTools (F12 in Chrome or Firefox), go to Application > Cookies, and compare the Domain column for each cookie to the address-bar URL. A domain that matches your site is first-party. A domain that differs is third-party. Consently's scanner automates this at scale: scan your site to see every cookie categorized by type and purpose.
Are third-party cookies still allowed in 2026?
Yes, in Chrome. Google's Privacy Sandbox status page (December 2025) confirms third-party cookies are available. Chrome reversed its blanket-removal plan in July 2024. It confirmed no separate consent prompt in April 2025. Safari and Firefox block them by default regardless.
Should I block third-party cookies?
Blocking third-party cookies in your browser settings reduces cross-site ad tracking with minimal breakage for most sites. Safari and Firefox already block known trackers by default. Blocking is not total privacy protection: fingerprinting and server-side tracking can still identify users without any cookies. On your own site, browser blocking is separate from the consent management you owe visitors under GDPR and CCPA.
Are first-party cookies safe?
First-party cookies carry lower privacy risk than third-party cookies because they are confined to one site. They cannot track you across the web. However, "first-party" does not mean fully private. A first-party cookie can still send your behavior data to a third-party server, via server-side tagging or tools like GA4. First-party analytics cookies still require consent in the EU. Lower risk is not no risk.
Do first-party cookies need consent under GDPR?
Strictly necessary first-party cookies do not require consent. They are exempt because removing them would break the site's basic function. First-party analytics cookies generally do require consent under GDPR and the ePrivacy Directive: they identify users and are not strictly necessary. Source: GDPR.eu. The exemption for "privacy-preserving analytics" exists but is narrow and jurisdiction-specific; most EU data protection authorities require opt-in for standard analytics cookies.
Is Google Analytics a first-party or third-party cookie?
GA4's _ga cookie is technically first-party: Google's analytics script sets it on your domain, so the domain matches your address bar. This does not mean the data stays with you. The behavioral data collected is sent to Google's servers. First-party describes the storage location, not the data controller. Under GDPR, the _ga cookie still requires consent because it identifies users and sends personal data to a third party (Google). For how to classify it in your consent banner, refer to the cookie categories guide linked in the comparison section above.
What is the difference between first-party data and first-party cookies?
First-party data is any information you collect directly from your audience: email addresses, purchase history, survey responses, behavioral data from your own analytics. A first-party cookie is one technical mechanism for collecting and storing that data in a user's browser. Not all first-party data comes from cookies (CRM data and email sign-ups are first-party data with no cookie involved). Not all first-party cookies produce first-party data you own (GA4 is a first-party cookie whose data goes to Google). For the full distinction, see the first-party data guide linked earlier in this article.
