Third-Party Cookie Tester

A cookie has no party of its own. The same small string, set by the same server, is first-party when you visit that server’s site and third-party when another site embeds it. Everything interesting about third-party cookies follows from that relationship, which is why a page cannot learn how your browser treats them by looking at itself.

The idea is older than most of the arguments about it. RFC 6265, the cookie specification of April 2011, already called third-party cookies particularly worrisome. A page pulls resources from other servers, such as advertising networks, and those servers can recognise you on every site that embeds them. The same document noted that browsers varied widely: some refused to send cookies in third-party requests, others refused to store cookies from third-party responses.

What makes a site a site

Browsers do not compare whole addresses. The HTML Standard defines a site as a scheme together with a registrable domain, and the URL Standard says how to find that domain: take the public suffix of the host from the Public Suffix List, then add the one label in front of it. If the host is not a domain at all, or is nothing but a public suffix, there is no registrable domain and the site is the scheme and the host themselves.

That list does a lot of quiet work. It holds the familiar endings such as com and org, and a private section where companies register names under which strangers get their own subdomains. Cloudflare’s entry there includes pages.dev. So b2kit.pages.dev is a registrable domain in its own right, as unrelated to b2kit.com as any two strangers on the web, even though both serve the same pages.

The same rules settle a smaller case. An IP address such as 127.0.0.1 is not a domain, and the public suffix of localhost is localhost itself. Each is therefore its own site, so a page on one address that embeds the other is a cross-site embed, exactly as on the public web.

Why the test needs a second site

A page reading its own cookies proves nothing about third parties. The test has to put a frame from the other site inside this page, ask that frame to set a cookie, and see whether it reads it back. The two pages talk by posting messages, and each accepts messages only from the one origin it expects, replying to that exact origin and never to anyone who asks.

Keeping a cookie is only half the story. The other half is whether the embedded copy shares its cookie jar with the same site visited directly. The tool answers that by opening the helper site as itself in a new tab, where it stores a random marker. The frame then looks for that marker. If it sees it, the jar is shared, and sharing is what lets a third party follow you from site to site.

Every marker is 32 random hexadecimal characters. Each is deleted as soon as it has been read, and the deletion is read back, because while a cookie exists the browser sends it to its host with later requests. Nothing is kept on a server.

Here is a worked example you can repeat. In development the tool page runs on 127.0.0.1 and the helper on localhost. In Chromium 145 with a fresh profile and default settings, the helper kept an ordinary cookie, kept one marked Partitioned, and saw the marker its own tab had set: a shared jar, so the verdict was allowed, by rule R1 of the decision table. With the setting that blocks third-party cookies switched on, the ordinary cookie was refused while the partitioned one was kept, and storage access was denied. The verdict was blocked, by rule R4.

That second result explains a choice in the decision table. Blocked means an ordinary third-party cookie was refused. Partitioned means it was kept, but in a jar separate from the site’s own. A browser that keeps only cookies which explicitly ask to be partitioned has still blocked the kind that follows you around.

How the engines describe themselves

Each statement below comes from the vendor’s own documentation, carries the date it was published or last changed, and may already be out of date.

Mozilla’s documentation on state partitioning describes a broad effort to give every website a user visits its own partitioned storage, and says it has been on by default since Firefox 103. Its guide to third-party cookies, last changed in June 2026, says Firefox enables Total Cookie Protection when Enhanced Tracking Protection is on, as it is by default, giving third-party cookies a separate jar per site. In this tool’s terms, that is the partitioned case.

WebKit announced in March 2020, in a post by John Wilander, that Safari 13.1 on macOS, and iOS and iPadOS 13.4, block cookies for cross-site resources by default across the board. The same post points embedded services that still need their cookies to the Storage Access API, which Safari had shipped two years earlier. Mozilla’s guide adds that Safari users can turn the protection off as a whole, but cannot allow cookies for one frame in settings: that happens only through the Storage Access API.

Google’s plans have shifted; its own post says it had been exploring a new approach the summer before. On April 22, 2025, Anthony Chavez wrote for the Privacy Sandbox team that Chrome would keep its current approach of offering users a choice about third-party cookies in its settings, with no new standalone prompt, and that Incognito mode already blocks them by default. Mozilla’s guide likewise says Chrome does not block them by default.

Partitioned cookies are the opt-in middle road. Google’s documentation on CHIPS describes a Partitioned attribute that ties a cookie to the top-level site where it was set, supported by default since Chrome 114. It also says that when third-party cookies are blocked, CHIPS and the Storage Access API are among the only ways to use cookies across sites. Mozilla notes the contrast with Firefox: state partitioning applies to everything by default, while CHIPS is something a cookie must ask for.

What blocking does and does not stop

The Storage Access API is the official way back in. An embedded frame calls hasStorageAccess to learn whether it already reaches its unpartitioned cookies, and requestStorageAccess to ask, during a click or tap. The specification lets browsers refuse, and they do. In the blocked run above, Chromium refused because the helper had never been interacted with as a top-level site.

This is why sign-in widgets, comment boxes and embedded players behave differently from one browser to the next. A frame that expects to find your session finds an empty jar or a partitioned one. WebKit’s advice to such services was to hand a token to the embedding site so it can start its own first-party session, to use the Storage Access API, or to rely on a temporary allowance for popups.

None of this stops the site you are on from remembering you. A first-party cookie is untouched by every setting discussed here, and so is anything a site learns because you signed in to it. Blocking third-party cookies narrows who can recognise you across sites. It does not make you anonymous anywhere.

Nor does it stop fingerprinting. The W3C note on mitigating browser fingerprinting, published in September 2025, explains that exposing the settings and characteristics of a browser allows fingerprinting, that it can happen without your knowledge, and that clearing cookies or using a VPN does not prevent it. Sites can combine what they know about one user even where a cookie policy blocks cookies between them. The browser facts this tool lists, from the user agent to the screen size, are typical ingredients.

The tool also reads two signals the page itself can see. Global Privacy Control, an editor’s draft at the W3C, exposes navigator.globalPrivacyControl so a script can learn whether the browser sent the matching request header. The older Do Not Track value appears beside it. Both are requests. Neither blocks anything.

What the test cannot tell you

The result describes one browser profile, with its current settings and exceptions, at the moment you pressed the button. A private window, another profile or a browser update can answer differently, and so can a site you have already granted storage access. The test cannot see trackers that do not use cookies, and it cannot prove a browser will refuse every embed, only this one.

It also cannot run anywhere it likes. It needs this site’s second address, so it works only on b2kit.com and b2kit.pages.dev, plus the two development addresses. When the helper does not answer within eight seconds, the tool says so and reports the frame measurements as not run, never as a pass.