Quick answer: A first-party cookie belongs to the site in your browser's address bar. A third-party cookie belongs to a different site loaded through an ad, script, image, iframe, or other embedded resource. First-party cookies keep logins, carts, preferences, and site analytics working. Third-party cookies can support cross-site sign-in, advertising, and attribution, but browsers restrict them more heavily.
Browser context determines the distinction. A cookie used as first-party on one page can be third-party on another, regardless of which company wrote the code.
First-party vs third-party cookies at a glance
| Difference | First-party cookies | Third-party cookies |
|---|---|---|
| Site context | The cookie's site matches the top-level site | The cookie's site differs from the top-level site |
| Example | You visit shop.example, which uses a cookie for shop.example | shop.example embeds a resource that uses a cookie for ads.example |
| Common uses | Sessions, shopping carts, language, consent choices, site analytics | Cross-site sign-in, embedded services, advertising, retargeting, attribution |
| Cross-site reach | Sent only to the matching site and permitted subdomains | May be recognized when the same third party appears on several sites |
| Browser treatment | Generally available, though browser and user limits still apply | Often blocked, restricted, or partitioned |
Typical SameSite setting | Lax or Strict when cross-site access is not needed | None, together with Secure, when cross-site access is required |
| Privacy | Can still identify and track a visitor on one site | Can connect activity across sites when the browser allows it |
What is a first-party cookie?
A first-party cookie is set or read in a same-site context. The cookie's domain and scheme match the page the person is visiting.
Suppose someone opens https://shop.example. The site's server can return this header:
Set-Cookie: session_id=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
The browser stores the cookie for shop.example and sends it back on matching requests. Another site cannot read that cookie directly.
Common first-party cookie examples include:
- A session cookie that keeps a customer signed in
- A cart cookie that remembers selected products
- A preference cookie that stores a language or region
- A consent cookie that records a visitor's choices
- An analytics cookie that distinguishes visits on the same site
Both the server and JavaScript can set first-party cookies. Server-set cookies can use HttpOnly, which prevents JavaScript from reading them. The Secure, HttpOnly, and SameSite attributes control how the browser stores and sends a cookie. They do not change a first-party cookie into a third-party cookie.
What is a third-party cookie?
A third-party cookie is used when its site differs from the site in the address bar. It usually arrives through content embedded from another site.
For example, shop.example might load an iframe from payments.example. A response from the embedded site could include:
Set-Cookie: payment_session=xyz789; Path=/; Secure; HttpOnly; SameSite=None
While the person remains on shop.example, the browser treats the payments.example cookie as third-party. shop.example cannot read its value directly. The browser may send it only to payments.example, subject to its privacy settings and storage rules.
Third-party cookies have supported several kinds of cross-site behavior:
- Recognizing an account inside an embedded sign-in or payment flow
- Limiting how often the same ad appears
- Attributing a conversion to an ad shown on another site
- Retargeting visitors across sites
- Saving state for chat, video, maps, and other embedded services
The term third-party covers more than advertising. It describes the relationship between the cookie's site and the top-level page. The MDN guide to third-party cookies uses the more precise term cross-site cookie for this reason.
The difference depends on where the cookie is used
The same cookie can be first-party on one page and third-party on another.
Take a cookie for video.example:
- On
video.example, it is first-party. - Inside a
video.exampleplayer embedded onnews.example, it is third-party.
Company ownership does not decide the result. If one company owns both domains, the browser still sees a cross-site context. The reverse can also happen: JavaScript supplied by an analytics vendor can run on shop.example and write a cookie for shop.example. The browser treats that cookie as first-party even though a vendor supplied the script.
This technical classification says where the cookie works. It does not say who receives the data or whether the use respects a person's consent.
First-party cookies and first-party data describe different things
A cookie is a browser storage mechanism. First-party data describes the relationship between an organization and the people it serves.
First-party data can include purchases, product usage, support conversations, survey answers, and consented website events collected directly by the organization. It may live in a warehouse, CRM, or analytics platform without any cookie attached.
A first-party cookie may hold an identifier that links browser activity to first-party data. It can also feed data to outside vendors. Calling the cookie first-party does not make every downstream use first-party, anonymous, or consent-free.
Are third-party cookies going away?
There is no single deadline across every browser.
- Safari: WebKit blocks third-party cookies by default. It provides the Storage Access API for cross-site embeds that need user-approved cookie access.
- Firefox: Total Cookie Protection partitions third-party storage by top-level site, while Enhanced Tracking Protection blocks known cross-site trackers.
- Chrome: Google said on April 22, 2025 that it would keep Chrome's existing user-choice approach and would not add a new standalone third-party cookie prompt. Chrome Incognito blocks third-party cookies by default, and users can block them in regular browsing.
That makes the old claim that Chrome would remove all third-party cookies in 2024 incorrect. Sites should still expect them to be unavailable for a meaningful share of visitors because of browser defaults, privacy settings, extensions, and consent choices.
Critical functions should work without unrestricted third-party cookies. Depending on the use case, alternatives include a first-party session, OAuth, the Storage Access API, or partitioned cookies such as CHIPS.
How to check first-party and third-party cookies
Chrome DevTools shows which sites store cookies and whether the browser found a cross-site issue:
- Open the page in Chrome.
- Open DevTools, then select Application.
- Under Storage, expand Cookies.
- Select each listed origin. A cookie for the top-level site is first-party in that context. A cookie used by another listed site is third-party.
- Check the
Domain,SameSite,Secure, andPartition Keycolumns. Chrome places a warning icon beside affected third-party cookies. - Open Network, reload the page, select a request, and open its Cookies tab to see cookies sent, received, or blocked on that request.
Chrome's cookie inspection guide documents each field. Searching your code for SameSite=None can also uncover cookies intended for cross-site use, but the attribute alone does not tell you how every request uses the cookie.
Running document.cookie in the Console is not a complete audit. It shows only cookies available to JavaScript for the current document. It omits HttpOnly cookies and does not show every cookie used by embedded sites.
Which type of cookie should you use?
Use the narrowest cookie scope that supports the feature.
- For authentication, prefer a host-only, server-set first-party cookie with
Secure,HttpOnly, and an appropriateSameSitevalue. - For carts, language, and consent choices, use first-party cookies with only the data and lifetime the feature needs.
- For embedded cross-site features, assume unrestricted third-party cookies may be unavailable. Test the flow with third-party cookies blocked before choosing an alternative.
- For analytics and attribution, collect consented events through a first-party endpoint and send only approved data to each destination.
First-party cookies are more dependable for site-specific functions. Privacy still depends on the purpose, retention period, security controls, consent state, and destinations.
How server-side tracking fits in
Server-side tracking changes how events are collected and routed while browser cookie classifications stay the same.
A site can send an event to an endpoint on its own domain, then process and route that event on infrastructure it controls. The setup may use a first-party cookie for session or visitor state, or it may use no cookie for a particular event. Either way, the server must enforce consent and data rules before forwarding anything.
Hardal's first-party stack and server-side analytics reduce dependence on third-party browser scripts and cookies. Start by auditing the cookies already on your site, remove the ones no feature needs, and test important journeys with third-party cookies disabled. The server-side tracking checklist covers the next implementation steps.