---
title: "First-party vs third-party cookies: what's the difference?"
description: 'Compare first-party and third-party cookies, current Chrome, Safari and Firefox rules, JavaScript versus server expiry limits, ad cookies and consent.'
canonical: https://plainrouter.com/definitions/first-party-cookies
last_updated: 2026-10-01
---

# First-party vs third-party cookies

A first-party cookie is used in the context of the site you are visiting; a third-party cookie is used by a different site embedded within it. This is a browser-context distinction, not a guarantee about who wrote the code, who receives the data or whether consent is needed.

## What is the difference?

| Question | First-party cookie | Third-party cookie |
| --- | --- | --- |
| Who sets it? | A response from the visited site, or permitted JavaScript executing in that site's page | A different site's embedded response or document, subject to browser permission |
| Which domain does it belong to? | A host/domain within the visited site | The embedded site's host/domain, used while another site is being visited |
| How long does it last? | Session or configured expiry, subject to browser limits and deletion | Also session or configured expiry; blocking and partitioning can restrict access |
| Is it blocked by default? | Generally available, but settings and tracking prevention still apply | Depends on browser, mode, site permissions and whether storage is partitioned |
| Typical uses | Login sessions, baskets, preferences and measurement | Embedded services and, where allowed, cross-site advertising measurement |

For example, `shop.example.com` and `collect.example.com` can be the same site, while `ads.example.net` embedded on that shop is a different site. “Same-site” is broader than “same-origin”: origins also distinguish the exact host, scheme and port.

A vendor's script running in your page can write a cookie under your site's domain. That cookie does not become third-party merely because the script was downloaded from a vendor. It can still support data sharing with that vendor. [MDN's cookie guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies)

## Are third-party cookies blocked in 2026?

**Policy checked October 1, 2026.** Browser settings, enterprise policies and exceptions can change what happens in a particular session.

| Browser | Published behavior | What to plan for |
| --- | --- | --- |
| Chrome | Google retained user choice rather than a universal third-party-cookie phase-out. Chrome lets people allow or block them; Incognito blocks them by default, with exceptions available. | Do not assume every Chrome visitor accepts them, or that Chrome removed them for everyone. |
| Safari / WebKit | ITP blocks third-party cookies by default; access can be granted through mechanisms such as the Storage Access API. | A working first-party visit does not establish embedded cross-site cookie access. |
| Firefox | Enhanced Tracking Protection blocks cross-site tracker cookies; Total Cookie Protection isolates other third-party cookies by the site being visited. | Partitioned storage is not one shared identifier available across every site. |

Sources: [Chrome policy update](https://privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies), [Chrome cookie settings](https://support.google.com/chrome/answer/95647), [WebKit tracking prevention](https://webkit.org/tracking-prevention/) and [Firefox tracking protection](https://support.mozilla.org/en-US/kb/third-party-trackers).

## JavaScript cookies versus server-set cookies

JavaScript can create a cookie with `document.cookie`; a server can send a `Set-Cookie` response header. `HttpOnly` prevents page JavaScript from reading or changing that cookie through the cookie API, while the browser can still attach it to eligible requests. It does not make the cookie anonymous or exempt from consent.

WebKit documents three limits worth distinguishing:

- **Seven days without user interaction:** ITP removes JavaScript-created cookies and other script-writable storage after this period. This is not a promise that every first-party cookie lasts seven days, nor a universal seven-day expiry from creation.
- **Twenty-four hours for detected link decoration:** JavaScript cookies created on an affected landing page have their expiry capped when ITP detects cross-site tracking through decorated links.
- **Seven days for detected third-party CNAME or IP cloaking:** this can cap cookies issued in HTTP responses too. Moving a cookie to a server or a collection subdomain does not guarantee unlimited lifetime.

These are conditional browser protections, not settings your application can override. [WebKit's current policy](https://webkit.org/tracking-prevention/)

## Common advertising cookies

| Name | Role | Important distinction |
| --- | --- | --- |
| `_fbp` | Meta browser-matching context stored in a first-party cookie | It is not your Pixel or dataset ID |
| `_fbc` | Meta click-matching context associated with a captured `fbclid` | It may be absent when there was no eligible Meta click |
| `_gcl_au` | A Google advertising-cookie name in the `_gcl_` family | It is not the `gclid` URL parameter; inspect the installed tag and actual cookie rather than assuming the values are interchangeable |

See [Meta's fbp and fbc fields](/library/fbp-fbc) and [GCLID: Google click IDs and redirect checks](/library/gclid). Google's [cookie documentation](https://policies.google.com/technologies/cookies?hl=en-US) describes the `_gcl_` family as supporting ad and conversion measurement. These examples explain cookie roles; their presence does not establish consent or prove that an ad caused a purchase.

## First-party cookies still need a purpose and permission

First-party status does not make an advertising cookie strictly necessary. Under UK PECR, non-exempt storage/access needs consent; narrowly defined exceptions depend on purpose and conditions, not just the domain. Other jurisdictions have their own requirements, and personal-data law also applies where relevant. Use the ICO's current [storage/access guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/) and [exceptions](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/what-are-the-exceptions/) when assessing a UK implementation.

Plainrouter's server-owned `pr_vid` visitor cookie is `HttpOnly` and is issued only after full consent. Arrival collection omits cookies and does not issue a visitor cookie; conversion identity is a separate flow. Inspect the browser's Storage/Application panel, not `document.cookie`, to check an HttpOnly cookie. [Signals serving and cookie behavior](https://plainrouter.com/docs/signals/configure-serving)

For the broader collection relationship, see [what first-party data means](/definitions/first-party-data).

## Frequently asked questions

### Are first-party cookies safe?

The label alone cannot establish safety. Review what the cookie contains, who can access it, its scope and lifetime, and security attributes such as `Secure`, `HttpOnly` where appropriate, and `SameSite`. A cookie can be technically secure while still being used for an inappropriate purpose.

### Do I need a cookie banner for first-party cookies?

That depends on the purpose, audience and applicable law. Where prior consent is required, collect it before the restricted storage/access and make refusal and withdrawal effective. An eligible exception may remove that consent requirement; displaying a banner by itself never makes the implementation compliant.

### Can a server set cookies?

Yes, through `Set-Cookie`; server-side does not mean cookieless. For that architecture comparison, read [cookieless tracking versus server-side tracking](/library/cookieless-tracking).