Third Party Cookie: Function, Tracking & Usage

Third-party cookies are HTTP cookies set by domains other than the one currently displayed in your browser's address bar. Also referred to as cross-site cookies, they allow servers to track activity across multiple websites for advertising and analytics. If you rely on behavioral targeting or multi-site attribution, you need to understand which browsers block these cookies and how to replace their functionality.

What is Third Party Cookie

A third-party cookie belongs to a domain different from the site you are actively visiting. While first-party cookies match the address bar domain and handle login sessions or cart data, third-party cookies activate when a page loads external components such as banner advertisements, social media widgets, or analytics scripts hosted on other servers. Your browser sends these cookies back to the external domain on subsequent requests, allowing that domain to recognize you across different sites.

Why Third Party Cookie matters

• Cross-site tracking: Advertisers use these cookies to build profiles of your browsing history across unrelated sites, enabling retargeting campaigns based on products you viewed elsewhere.
• Attribution and analytics: They power conversion tracking when users navigate from a publisher site to a merchant site, showing which referral sources drive sales.
• Single sign-on: Legitimate use cases include embedded sign-in widgets that share authentication states across related domains like shop.example and forum.example.
• Regulatory exposure: Data collected without explicit consent violates GDPR and CCPA, exposing businesses to fines and requiring consent management platforms.
• Browser deprecation: [As of July 2020, Safari, Firefox, and Brave block third-party cookies by default] (Wikipedia), while [Google Chrome began blocking them for 1% of users in January 2024] (BBC News). [Google reversed its plan to fully deprecate third-party cookies in Chrome in July 2024] (CBS News).
• Scale of tracking: [As of 2014, some websites set cookies readable by over 100 third-party domains, with the average site setting 10 cookies and some exceeding 800 total cookies] (WebCookies.org).

How Third Party Cookie works

1. A user visits Site A (example.org), which contains an advertisement or iframe loaded from Site B (ad.network.com).
2. Site B sets an HTTP cookie for its own domain (ad.network.com) when serving the component.
3. The user later visits Site C (another site using the same ad network), which also embeds Site B content.
4. The browser automatically sends the existing Site B cookie with the request to Site B, allowing the server to identify the user across both Site A and Site C.
5. Site B uses the HTTP referer header to record which specific pages the user viewed, building a detailed browsing history for targeted advertising.

Third Party Cookie vs First Party Cookie

Use first-party cookies for site functionality and user preferences. Use third-party cookies only when you specifically need to track or identify users across different domains.

Second-party cookies represent a hybrid model where first-party data is shared between trusted partners (such as a coffee shop sharing customer preferences with a nearby bakery) with user consent.

Best practices

• Audit your code: Search for SameSite=None to identify cookies intended for cross-site use. Chrome’s DevTools Issues panel and Firefox Storage Inspector highlight affected cookies.
• Set SameSite=Lax by default: This prevents cookies from being sent in third-party contexts while allowing top-level navigation requests. Only use SameSite=None when embedding cross-site content like sign-in widgets.
• Require Secure for cross-site: When using SameSite=None, always include the Secure attribute to ensure HTTPS transmission.
• Test with blocking enabled: Verify site functionality in Safari, Firefox, and Brave where third-party cookies are blocked by default, and in Chrome with third-party cookies disabled via settings.
• Implement CHIPS for related sites: If you operate multiple related domains, use Cookies Having Independent Partitioned State (CHIPS) by adding the Partitioned attribute. This creates isolated cookie jars per top-level site, preventing cross-site tracking while maintaining functionality.
• Use Storage Access API for embeds: For legitimate cross-domain iframes, request storage access permission on a per-frame basis rather than relying on passive third-party cookies.
• Prepare alternatives: Transition toward contextual advertising, server-side tracking, or Privacy Sandbox APIs to reduce reliance on cross-site cookies.

Common mistakes

• Mistake: Assuming cookies work cross-site without SameSite=None. Modern browsers default to Lax, which blocks your cookie in third-party contexts. You will see authentication failures or broken embedded widgets. Fix: Explicitly set SameSite=None; Secure for intentional cross-site cookies, or migrate to CHIPS or Storage Access API.

• Mistake: Not testing in privacy-focused browsers. If you only test in Chrome with default settings, you miss breakage affecting Safari and Firefox users (together representing substantial market share). Fix: Include Safari and Firefox in your QA process with Intelligent Tracking Prevention and Enhanced Tracking Protection active.

• Mistake: Ignoring partitioned cookie options. You might expose user data across unrelated sites when you only need session persistence within specific embedded contexts. Fix: Add the Partitioned attribute (CHIPS) to isolate cookies per top-level site when cross-site sharing is unnecessary.

• Mistake: Violating consent requirements. Setting tracking cookies before obtaining user consent violates GDPR and CCPA, risking fines. Fix: Implement a Consent Management Platform (CMP) that blocks third-party cookie setting until the user opts in.

• Mistake: Relying on third-party cookies for security logic. These cookies are vulnerable to cross-site request forgery (CSRF) and are accessible across domains. Fix: Use first-party cookies with SameSite=Strict for security-sensitive operations and validate tokens server-side.

Examples

Example scenario: A user browses running shoes on retailer.example. The page loads a display ad from adtech.example, which sets a third-party cookie. Later, the user visits news.example, which also uses adtech.example. The ad network reads its cookie and serves an ad for those specific running shoes.

Example scenario: A publisher runs review-site.example and includes affiliate links to partner-store.example. When a user clicks the link, partner-store.example sets a third-party cookie to track the referral source. If the user purchases within the cookie duration, the publisher earns commission.

Example scenario: A company operates shop.example, forum.example, and service.example. They embed a sign-in widget hosted at auth.example. Using the Storage Access API, auth.example requests permission to access its first-party cookie after the user interacts with the widget, enabling seamless authentication across all three properties without traditional cross-site tracking.

FAQ

What is the difference between first-party and third-party cookies? First-party cookies match the domain in your address bar and handle functions like keeping you logged in or remembering your cart. Third-party cookies belong to different domains and track your activity across multiple sites for advertising or analytics. The distinction depends entirely on which domain sets the cookie, not the company ownership.

Why are third-party cookies being blocked? Browsers block these cookies to prevent cross-site tracking that builds detailed user profiles without consent. Privacy regulations like GDPR and CCPA also require explicit permission for such tracking. Blocking protects users from invasive advertising, spam targeting, and potential identity theft from aggregated browsing data.

Which browsers block third-party cookies by default? [Safari, Firefox, and Brave have blocked third-party cookies by default since July 2020] (Wikipedia). Chrome blocks them only in Incognito mode or when users manually enable the setting, though [Google tested blocking for 1% of users in January 2024] (BBC News) before [reversing full deprecation plans in July 2024] (CBS News).

How do I audit my site for third-party cookie dependencies? Search your codebase for SameSite=None, which indicates cookies intended for cross-site use. Check Chrome’s Issues panel or Firefox Storage Inspector for third-party cookie warnings. Test functionality with third-party cookies disabled in browser settings to identify broken features like embeds or authentication.

What is replacing third-party cookies? Alternatives include Google's Privacy Sandbox APIs (for interest-based targeting without individual tracking), contextual advertising (targeting based on page content rather than user behavior), first-party data strategies, and authenticated identity solutions. For technical replacements, use CHIPS for partitioned storage or the Storage Access API for embedded cross-site content.

What is CHIPS? Cookies Having Independent Partitioned State (CHIPS) allows developers to mark cookies with a Partitioned attribute. The browser stores these cookies in separate jars per top-level site, preventing cross-site tracking while allowing functionality across related domains you control. This works as an alternative to traditional third-party cookies for multi-site operators.

How does the SameSite cookie attribute affect third-party cookies? The SameSite attribute controls when browsers send cookies. Strict blocks all cross-site requests. Lax allows cookies during top-level navigation but blocks them in embedded contexts (the default in Chrome). None allows cross-site cookies but requires the Secure attribute. Without explicit settings, browsers increasingly default to blocking third-party contexts.