# Is Chrome removing third-party cookies? No, it kept them > Chrome is not removing third-party cookies: Google dropped the phase-out and then the prompt. A jar per account matters as much as it did before. Source: https://mosaicbrowser.com/blog/chrome-keeps-third-party-cookies ## Chrome kept third-party cookies. What that means for cookie jars Chrome is not removing third-party cookies: Google dropped the phase-out and then the prompt. A jar per account matters as much as it did before. ![Chrome kept third-party cookies, beside a screenshot: importing a cookie jar into a Mosaic profile](https://mosaicbrowser.com/covers/chrome-keeps-third-party-cookies.webp) Chrome is not removing third-party cookies. Google spent years on a plan to phase them out, postponed it several times, replaced it with a plan to ask every user to choose, and then dropped the prompt as well. In an ordinary Chrome window a third-party cookie works today exactly as it did before any of that started, unless the person has blocked it in Settings › Privacy and security. For anyone keeping several accounts apart, that decision changes less than the headlines suggested. The cookie that links two accounts most reliably is not a third-party one. ## What Google decided, and in what order The original plan was to stop Chrome sending cookies to embedded third parties and to give advertisers a set of browser APIs instead: Topics, Protected Audience, Attribution Reporting and the rest of Privacy Sandbox. The deadline slipped more than once, because the replacement APIs had to work for the ad industry and satisfy the UK's competition regulator at the same time. Then Google stopped. Instead of turning third-party cookies off, it said Chrome would show people a choice. Later it said it would not show that prompt either, and that the existing controls in Chrome's settings would stay as they are. The advertising half of Privacy Sandbox was retired afterwards, which turned the presence or absence of those APIs into a way to tell Chrome versions apart; we wrote up that side in [Privacy Sandbox APIs as a version tell](https://mosaicbrowser.com/blog/privacy-sandbox-apis-removed). What a Chrome user has now is three positions: | Where | Third-party cookies | | --- | --- | | A normal Chrome window, default settings | allowed | | A normal window, blocked in Settings › Privacy and security | blocked | | An Incognito window | blocked by default, and the whole jar is discarded when Incognito closes | Safari and Firefox went the other way years ago and restrict third-party cookies by default, so "the web without third-party cookies" already exists for a large share of visitors. It is just not Chrome's default. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: Local first](https://mosaicbrowser.com/features/local-first) ## A third-party cookie and a first-party cookie link accounts differently A third-party cookie belongs to a domain embedded in the page rather than the one in the address bar. A tracker that sits on site A and site B sets one cookie under its own name, and the browser hands it the same value on both. That is how one company recognises the same browser across many sites. It is cross-site tracking, and it is what the phase-out was about. Two accounts on the same site are a different problem. When you sign out of one account and into another, the site's own cookies are still in the jar: a device id, a consent record, an anti-fraud token, a "remember this browser" flag. They are first-party, so no browser setting in any of the three rows above stops them. The site reads them back on the next request and sees one browser carrying both logins. So the question that matters for multiple accounts was never "will Chrome block third-party cookies". It is "do these two accounts share a jar". If they do, the site that cares can join them with its own cookies, and the fingerprint and the IP address tell it the same thing from two more directions, which is the subject of [how to manage multiple accounts without getting them linked](https://mosaicbrowser.com/guides/how-to-manage-multiple-accounts-without-getting-linked). ## What keeping third-party cookies means in practice Embedded trackers keep working across sites in Chrome as it ships. If two of your accounts browse in one jar, an ad network that is on both sites sees one browser, even when the two sites never compare notes with each other. Blocking third-party cookies yourself is still a fair privacy choice, but it is a choice a page can notice. A Chrome window that refuses third-party cookies has moved off Chrome's default, and a script can find that out by trying to set one from an embedded frame. We would not tell anyone to leave it on for that reason alone; it is a trade worth knowing about. And a fresh jar is still the cleanest test of anything that depends on cookies. When we check whether an affiliate link credits a sale, the run that means something starts from a jar nobody has used, because an old cookie from an earlier click decides the result before the link does. The method is in [testing affiliate link tracking with a clean jar](https://mosaicbrowser.com/blog/testing-affiliate-link-tracking). ## One jar per profile, whatever Chrome decides In Mosaic every profile is its own browser with its own Chromium profile directory, so it has its own cookie jar. A cookie a site sets in one profile, first-party or third-party, is never sent from another. That holds whichever way Google moves its defaults, because it does not depend on blocking anything; the two jars simply never meet. Tesseract Chrome, our engine, keeps Chrome's cookie setting as stock Chrome ships it. We have not changed it. The jars are encrypted on disk with a key per profile, and they stay on your computer: Mosaic has no cloud copy of your profiles ([what local-first means here](https://mosaicbrowser.com/features/local-first) lists what our server does and does not know). You can import a jar as a JSON array, a `{cookies: [...]}` object, a Netscape `cookies.txt` file or a `Cookie:` header line, export it the same ways, and apply an import to a profile while its browser is open. Cookies are one of the three things a site uses to recognise a browser. The other two, the fingerprint and the exit address, are why a separate jar on its own is not enough, and the values a page reads for the first of those are listed in [browser fingerprint](https://mosaicbrowser.com/glossary/browser-fingerprint). ## Questions ### Is Chrome removing third-party cookies? No. Google gave up the plan to phase them out, and then gave up the prompt it had proposed in place of the phase-out. In a normal Chrome window third-party cookies work unless the person blocks them in Settings, Privacy and security. ### Does Incognito block third-party cookies? Yes, by default. An Incognito window in Chrome blocks third-party cookies unless you allow them, and it throws its whole jar away when the last Incognito window closes. ### If third-party cookies went away, could a site still link two accounts? Yes. A site's own first-party cookies come back to it on every visit from the same browser, whichever account is signed in, so two logins from one jar are visible to that site with or without third-party cookies. ### Does Mosaic block third-party cookies? Tesseract Chrome leaves Chrome's cookie setting as stock Chrome ships it; we have not changed it. What Mosaic adds is a separate cookie jar per profile, encrypted on disk, so a cookie set in one profile never reaches another. ## Related [Privacy Sandbox is retired, and its APIs are a version tell](https://mosaicbrowser.com/blog/privacy-sandbox-apis-removed): Chrome is removing Topics and Protected Audience release by release, so whether runAdAuction exists tells a page which Chrome you really are. [How to manage multiple accounts without getting them linked](https://mosaicbrowser.com/guides/how-to-manage-multiple-accounts-without-getting-linked): Accounts get linked by shared cookies, IPs, fingerprints and habits. Give each its own profile, exit and history, then test it before you trust it. [Testing whether your affiliate links track, with a clean jar](https://mosaicbrowser.com/blog/testing-affiliate-link-tracking): To test whether an affiliate link tracks, click it from a browser with an empty cookie jar and read what it set. An old click's cookie can spoil the test. [Local first: your profiles stay on your computer](https://mosaicbrowser.com/features/local-first): Mosaic has no cloud copy of your profiles. Profiles, cookies and proxies stay on your computer, encrypted on disk, with app lock, daily backups and a trash. [Browser fingerprint: what a site can read about your machine](https://mosaicbrowser.com/glossary/browser-fingerprint): A browser fingerprint is the set of values a site reads about your browser and computer, which together recognize you without cookies. What goes into one. [App-Bound Encryption, and why tools stopped reading Chrome's cookies](https://mosaicbrowser.com/blog/chrome-app-bound-encryption): App-Bound Encryption ties Chrome's cookie key on Windows to Chrome itself, so tools reading the Cookies file broke. Export from inside the browser. [Device-bound sessions and the end of copying a cookie](https://mosaicbrowser.com/blog/device-bound-session-credentials): With Device Bound Session Credentials in Chrome, a site reissues its session cookie only to the device with the key. A copied cookie lasts until it expires. [Chromium's mock keychain, and why we encrypt the store](https://mosaicbrowser.com/blog/mock-keychain-cookies): Chromium's --use-mock-keychain keeps cookie encryption on but uses a password from its own source. We read a live session cookie off disk, then sealed it. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.