First-party cookies are used in the context of the site a person is visiting. Third-party cookies are used in a cross-site context, such as a cookie for an unrelated service embedded in that page. The distinction describes browser context. It does not, by itself, tell you who receives the data, whether the cookie is necessary or whether consent is required.
For website owners, those are separate questions. This guide explains the difference through examples, shows what to inspect and connects the technical classification to consent decisions. For current browser restrictions, use our third-party cookies and browser rules guide.
First-party vs third-party cookies at a glance
A cookie is a small piece of browser-stored data associated with a domain. A server can set it in an HTTP response, or page JavaScript can create a cookie where permitted. The browser can send applicable cookies with later requests. MDN's HTTP cookie guide
| Question | First-party context | Third-party context |
|---|---|---|
| Relationship to the page | Cookie belongs to the same site as the page being visited | Cookie belongs to a different site used within the page |
| Illustrative use | A shop remembers a basket on its own site | An embedded service uses its own cookie inside the shop |
| Can it support analytics or advertising? | Yes, depending on the implementation | Yes, depending on the implementation |
| Is it automatically necessary? | No | No |
| Does the classification establish who receives data? | No; inspect outgoing requests and server forwarding | No; inspect the recipients and their purposes |
A cookie can be first-party when someone visits its site directly and third-party when that site is embedded elsewhere. “Third-party” does not necessarily mean a different company owns the domain. MDN's explanation of cross-site cookies
A site is not always one hostname
Browser same-site rules generally consider the scheme, such as HTTPS, and the registrable domain, using the public suffix list. Two HTTPS subdomains of example.com can be same-site while remaining different origins. Cookie domain and path rules separately determine where a particular cookie can be sent. Do not classify every subdomain request as third-party or assume all same-site hosts receive the same cookies. Same-site and same-origin explained
Three practical cookie examples
These examples are illustrative. They are not observations from a customer website or fixed classifications for every implementation.
A shopping basket on the shop's own site
A visitor browses https://shop.example and adds a product. The shop sets a cookie scoped to its host to recognise the basket on the next page. That is a first-party context.
The review still needs the cookie's actual purpose, lifetime and use. A basket identifier used only to deliver the requested shopping function raises different questions from an identifier reused to build an advertising profile. Give those uses separate entries in your inventory even if the same technical identifier is involved.
Analytics supplied by an external vendor
A shop loads an external analytics script in its own page. The script can use the page's execution context to create a cookie for the shop, where browser rules permit it. It may then include information derived from that cookie in requests to an analytics service.
The cookie can therefore be first-party while the measurement data goes to another organisation. The script's download location, the cookie's domain and the event's recipient are three different facts to record. CNIL explicitly discusses first-party cookies and other alternatives that can still support advertising tracking. CNIL on alternatives to third-party cookies
A booking service embedded in an iframe
A page on https://shop.example embeds a booking service from https://booking.example. The embedded service attempts to use a cookie associated with booking.example. In that embedding context, the cookie is cross-site.
Now imagine the visitor opens https://booking.example directly. Its own cookie is used in a first-party context there. This is why a booking flow may work as a standalone page but fail inside an iframe. Inspect browser restrictions and the vendor's supported integration before changing consent settings.
Do first-party cookies need consent?
First-party status does not create a consent exemption. In the EU, Article 5(3) of the ePrivacy Directive addresses storing information on, or accessing information from, a person's device. Its exceptions cover transmission and what is strictly necessary to provide a service explicitly requested by the user. Assess purpose and applicable national rules. GDPR requirements apply separately where personal data is processed. ePrivacy Directive, Article 5(3)
A useful review asks:
- What user-requested function does this storage support?
- Is it necessary for that function, or does it serve an additional measurement or advertising purpose?
- Which parties receive information, and what can they do with it?
- What happens before a choice, after rejection and after withdrawal?
Avoid assigning “necessary” based on a vendor's name, a first-party domain or the fact that a cookie lasts only for a session. Document the function and processing instead. Our GDPR cookie consent guide covers the broader assessment.
California's sale and sharing analysis is also separate from browser cookie classification. For a covered business, examine the disclosures, recipients, purposes and applicable exceptions. Use the CCPA sale versus sharing guide rather than treating a first-party cookie as proof that no relevant disclosure occurs.
How to identify cookies on your website
Start with one important journey, such as entering a landing page and completing a test purchase. Record the browser version, region and saved consent state. Use test data and a dedicated profile so earlier choices do not obscure the result.
In Chrome DevTools:
- Open Application, expand Storage → Cookies, and select the relevant domain.
- Record the cookie name, domain, path, expiry and relevant flags. Inspect the partition key where present.
- Open Network, reload the page and inspect relevant requests. Check response
Set-Cookieheaders and request cookies, including blocking reasons. - Repeat before a choice, after rejection and after accepting only one optional purpose. Compare what changed.
Chrome documents the available cookie fields and filtering tools in its DevTools cookie guide.
Use the domain together with the top-level page and request context. A cookie's name alone is not enough to establish its owner or purpose. Avoid relying only on document.cookie, which does not expose cookies marked HttpOnly. MDN's cookie access guidance
For a useful inventory, capture more than a list of names:
| Record | Example question |
|---|---|
| Page and context | Is this the top-level site or an embedded service? |
| Cookie and storage scope | Which host, path and partition can use it? |
| Setter and purpose | Which script or response creates it, and why? |
| Recipients | Where does related data go from the browser and server? |
| Choice behaviour | Is it created before consent, after rejection or after acceptance? |
| Retention | How long is it configured to last, and what does the browser actually retain? |
A blocked cookie does not prove that no request or personal data left the browser. Likewise, browser developer tools cannot reveal every later server-to-server transfer. Combine these observations with your tag configuration, vendor documentation and server routing inventory.
What SameSite, HttpOnly and partitioning tell you
Cookie attributes answer specific technical questions. None is a label for legal permission.
SameSitecontrols when cookies may accompany cross-site requests.SameSite=NonerequiresSecure, but it does not override browser blocking or prove the cookie was used in a third-party context.HttpOnlyprevents JavaScript access to the cookie. It does not mean the cookie is anonymous, necessary or unrelated to tracking.Securerestricts transmission to secure connections, with browser handling for local development. It is not a consent control.Partitionedopts a cookie into partitioned storage, separating its state by top-level site. That separation changes its reach, not its underlying purpose.
These attributes should be interpreted alongside domain, path and browser behaviour. See the Set-Cookie reference.
Does server-side tracking make cookies first-party or consent-free?
Server-side tracking describes where events are processed. First-party versus third-party describes browser context. Neither term establishes that a particular data flow is permitted.
A collection endpoint on your own site may receive browser cookies and forward selected events to external platforms. Review both stages: what the browser stores or transmits, and what the server subsequently sends. Changing the hostname does not remove the need to identify recipients and honour applicable choices.
Our server-side tracking guide explains the architecture, filtering controls and operational trade-offs. Keep the browser-rules guide for compatibility questions and this comparison for classification questions.
FAQ
Can a third-party script set a first-party cookie?
Yes. An external script running in the page can create a cookie for that page's site where permitted. An iframe from another site has a different context. Inspect where the code runs, where the cookie is scoped and where related data is sent.
Are analytics cookies first-party or third-party?
They can be either, depending on the implementation. “Analytics” describes a purpose; “first-party” describes context. Determine the classification and consent requirements from the actual configuration and processing.
Are first-party cookies always safe?
No. First-party status does not establish security, limited retention or appropriate use. Review attributes, identifiers, access, recipients and purposes separately.
Does blocking third-party cookies stop all tracking?
No. Other cookies, browser storage, network requests and backend events can remain. Test actual collection and forwarding rather than relying on the absence of one cookie type.
Is a session cookie always necessary?
No. Session describes lifetime, not purpose. A short-lived advertising cookie does not become necessary simply because it is removed at the end of a browsing session.
Does SameSite=None mean a cookie always needs consent?
No. It is a browser attribute, not a legal classification. Assess the purpose, device access, applicable rules and exceptions. Equally, a different SameSite value does not establish a consent exemption.
Put the classification into practice
Start by mapping cookies, purposes and recipients on your site's most important journeys. Then check that the banner and tags implement the choices you describe.
For help with that work, explore our cookie consent implementation service or request a free consent audit. You can also return to all Cookies and tracking guides.
