First-Party, Third-Party and Partitioned Cookies

Key takeaways

• First-party and third-party describe context, not a cookie type: the same cookie can be either.
• Many browsers block or partition third-party cookies, but behaviour differs by browser, version and settings.
• A Partitioned cookie is keyed by the setting origin and the top-level site, so an embed cannot link visits across sites.
• MDN states that Partitioned requires the Secure attribute and recommends the __Host- prefix.
• Design embeds to degrade gracefully, and keep an inventory of every cookie your site and its embeds set.

Whose cookie is it?

The labels first-party and third-party describe a relationship, not a type of cookie. A cookie is first-party when its site matches the site shown in the browser address bar. It is third-party when the cookie belongs to a different site that is loaded inside the page, for example through an image, a script, an iframe or a tracking request. The same cookie can be first-party in one situation and third-party in another. A cookie from a video provider is first-party when you visit the provider directly, and third-party when the provider's player is embedded in someone else's article.

What first-party cookies are used for

First-party cookies carry most of the everyday state of the web. They keep you logged in, remember items in a basket, store a chosen language, and hold anti-forgery tokens. Because the site setting them is the site you chose to visit, they are widely accepted by browsers and are rarely blocked by default. Even so, they may still need user consent or notice in some regions, depending on what they do, which is covered in the privacy guide on this site.

What third-party cookies are used for

Third-party cookies appear when content from another site is embedded. Legitimate uses include a payment provider's frame that recognises a returning customer, an embedded chat widget that keeps a conversation, a single sign-on session shared between related services, and a map or video provider that stores a preference. The same technique has also been used for cross-site tracking and advertising, where one company's cookie follows a person across many unrelated websites. That second use is the main reason browsers and regulators have paid close attention to the whole category.

Three kinds of cookie context

Why do browsers restrict third-party cookies?

Cross-site tracking relies on a cookie that is the same wherever a person goes. If a third-party host sets a cookie in an embed on site A, and receives it again in an embed on site B, it can link the two visits. Several browsers now block third-party cookies by default or partition them, and others offer settings and tracking prevention features that restrict them. The details differ between browsers and have changed over the years, so a statement such as current browsers generally limit third-party cookies is safer than any absolute claim. Always test your embed in several browsers, in normal and private windows, with default settings.

• Some browsers block third-party cookies by default.
• Some partition them by the top-level site.
• Some allow them but offer user controls and warnings.
• Behaviour can differ again in private browsing modes and with extensions installed.

What is partitioned storage?

Partitioning is a middle path. Instead of a single cookie jar entry per name, domain and path, a partitioned cookie is keyed by one extra piece of information: the top-level site on which the embed appeared. A cookie set by an embedded widget while the user is on site A is stored in a partition for site A. When the same widget appears on site B, it gets a different, empty partition. The widget can still remember state within each site, but it cannot recognise the person across both.

What are the Partitioned attribute and CHIPS?

The attribute that opts a cookie into this model is called Partitioned, and the proposal behind it is known as Cookies Having Independent Partitioned State, or CHIPS. A header might look like Set-Cookie: __Host-chat=xyz; Secure; Path=/; SameSite=None; Partitioned. Browsers that support the feature require the Secure attribute alongside it, and commonly the __Host- prefix is used in examples because it makes the cookie host-only. Support is not universal and has been rolling out over time, so check current compatibility tables before depending on it.

Partitioned cookies are meant for cases where an embedded service needs per-site state without cross-site identity. Examples include a chat widget remembering which conversation belongs to this host site, an embedded map keeping a setting, or a payment frame holding a short-lived session. They are not a way to rebuild cross-site tracking, and they are not a replacement for sign-in flows that genuinely need a shared identity across sites.

What can I do when third-party cookies fail?

If your design breaks without third-party cookies, consider whether you really need an embedded cross-site session. Common alternatives include these approaches.

• Serve the embedded feature from a subdomain of the host site so that it becomes first-party.
• Use a redirect-based sign-in flow with tokens passed through the URL fragment or a secure back-channel, rather than relying on a silent cookie in a frame.
• Use browser storage access APIs where available, which let an embed request access after a user gesture. Availability differs between browsers.
• Pass short-lived tokens in request headers from your own scripts instead of relying on the cookie jar.

How do I test embedded cookie behaviour?

Build a small test page on a different domain that embeds your widget, and observe the cookie in developer tools. Check the application or storage panel to see whether the cookie was stored, in which partition, and whether a blocked cookie warning appears. Test in at least two engines, with default privacy settings, and again after enabling stricter tracking prevention. Also test the case where a user has chosen to block all third-party cookies, since a robust embed shows a helpful message rather than failing silently.

Takeaways

First-party and third-party describe context. Third-party cookies face restrictions in many browsers, so design embedded features to degrade gracefully. Where state per host site is enough, partitioned cookies offer a privacy-friendlier approach, subject to browser support. Whatever you choose, document the cookies your site and its embeds set, so you can describe them accurately in your privacy notice.

Sources and further reading

• MDN: Cookies Having Independent Partitioned State (CHIPS): partitioned cookies keyed by the setting origin and the top-level site, and the Secure requirement.
• MDN: Set-Cookie header: each attribute (Domain, Path, Expires, Max-Age, Secure, HttpOnly, SameSite, Partitioned) and the cookie prefix rules.
• MDN: Using HTTP cookies: session and permanent cookies, deleting a cookie, regenerating session cookies at login, and why cookies suit storage poorly compared with Web Storage.

Frequently asked questions