CHIPS and Partitioned Cookies: How Chrome's Storage Partitioning Affects Multi-Profile Isolation

Two months ago, someone in a Discord group I lurk asked why their separate profiles were being recognised as the same browser in their isolation tests. Same setup they'd used for years — separate proxies, different fingerprints, isolated cookie jars. Worked fine until Q2 2026. Then the test pages started reporting one shared identity.

The culprit wasn't canvas. Wasn't WebGL. Wasn't even cookies in the traditional sense.

It was partition key metadata.

Every profile reported the same malformed partition key format — a unique signature that tied "separate" profiles together. A site's script didn't need to track cookies across profiles. It just needed to notice that all these profiles had the same broken implementation of a feature real browsers handle automatically.

That's the thing about browser privacy features. They're designed to prevent tracking. But if your antidetect browser implements them wrong — or doesn't implement them at all — the implementation gap becomes the tracking signal. And CHIPS is subtle enough that most people have no idea it exists.

What We're Building

By the end of this tutorial, you'll understand:

What CHIPS (Cookies Having Independent Partitioned State) actually does
How Chrome's broader Storage Partitioning affects localStorage, IndexedDB, and more
Why this matters for antidetect profile isolation
How to test whether your profiles handle partitioning correctly
What native engine control means for partition key generation

We're going deep on a browser feature most operators don't know exists. This isn't "how to set up profiles 101." If you want that, start with the CreepJS testing walkthrough. This is for people who need to understand the internals.

Prerequisites

An antidetect browser profile (we'll use JustBrowser in examples, but the concepts apply to any tool)
Basic understanding of how cookies work (first-party vs third-party)
Chrome DevTools familiarity (Application tab)
20-30 minutes

If you're fuzzy on browser fingerprinting fundamentals, the WebGL fingerprinting guide and audio/font fingerprinting overview might help. Not required.

Step 1: Understand What CHIPS Actually Does

Before CHIPS, third-party cookies worked like this: if tracker.com set a cookie while embedded on site-a.com, that same cookie was readable when tracker.com was embedded on site-b.com. Classic cross-site tracking. Surveillance capitalism's bread and butter.

CHIPS changes the model. Now, cookies with the Partitioned attribute get a separate storage bucket for each top-level site (also called the "partition key"). The cookie tracker.com sets on site-a.com is invisible to tracker.com on site-b.com. Same domain, different partition, different cookies.

Here's how it looks in practice:

# Old model (pre-CHIPS)
site-a.com embeds tracker.com → sets cookie "user_id=abc123"
site-b.com embeds tracker.com → reads cookie "user_id=abc123" ← same cookie!

# CHIPS model (Chrome 146+)
site-a.com embeds tracker.com → sets partitioned cookie "user_id=abc123" [partition: site-a.com]
site-b.com embeds tracker.com → cannot read that cookie ← different partition
site-b.com embeds tracker.com → sets new partitioned cookie "user_id=xyz789" [partition: site-b.com]

The partition key is typically the eTLD+1 of the top-level document. So https://shop.example.com/cart has partition key example.com.

"Okay," you're thinking, "this sounds like it helps privacy. Why do I care for profile isolation?"

Because the partition key itself is metadata. And metadata leaks.

Step 2: Why Partition Keys Matter for Profile Isolation

When you run multiple antidetect profiles, each profile should behave like a completely separate browser instance. Separate cookies, separate storage, separate identity.

But here's the catch: partition keys are generated by the browser engine. If your antidetect browser doesn't properly isolate partition key generation per profile, all your profiles share the same partitioning behavior. Which means:

Partition key format leakage. If your browser generates partition keys differently than real Chrome — maybe a slightly different format string, or missing some component — that format becomes a fingerprint. Every profile using that browser shares the same "wrong" format.
Cross-profile partition data bleeding. Some antidetect implementations share underlying storage between profiles at the engine level and only isolate at the JavaScript layer. Partitioned storage can bypass those JS-level barriers.
Missing partition support entirely. If your browser doesn't support CHIPS at all, third-party embeds can still track across top-level sites within your profile. Worse, the lack of partitioning is itself detectable — sites can test whether their partitioned cookies work correctly.

I've seen people assume profile isolation means cookie isolation. It doesn't. Not anymore.

In 2026, profile isolation means partition key isolation. If two profiles have the same partition key implementation characteristics, a site's script can correlate them — even if they have zero shared cookies. That matters for privacy, QA and testing, and for teams keeping client profiles separate. I spent an embarrassing amount of time debugging a "fingerprint leak" that turned out to be partition metadata. Different fingerprints, same partition signature. Oops.

Step 3: The Broader Storage Partitioning Picture

CHIPS is just cookies. Chrome's Storage Partitioning extends the same concept to:

localStorage — Partitioned by top-level site
sessionStorage — Already origin-scoped, but nested iframes now partition differently
IndexedDB — Partitioned, affects embeds that store structured data
Cache API — Service worker caches are partitioned
SharedWorker — Workers are now partitioned by top-level origin
BroadcastChannel — Can't communicate across partition boundaries

This matters for profile isolation because sites increasingly use these APIs for identity persistence. They might not set a cookie at all — instead storing an identifier in IndexedDB and checking it cross-context.

Real scenario: a platform embeds a "security" iframe storing a device fingerprint in IndexedDB. Pre-partitioning, that fingerprint was readable from any site embedding the same iframe. Now each top-level site gets a separate IndexedDB instance.

If your antidetect browser doesn't handle partitioned IndexedDB correctly, you might leak fingerprints across contexts or fail to persist them where they should persist. Frustrating? Yeah. I'd rather worry about canvas hashes than debug IndexedDB partition keys at 2am. But here we are.

The "right" behavior depends on your use case — profile isolation wants separate partitions per profile, while persistent login wants partition persistence within a profile's context.

Step 4: Testing Your Profiles

Here's how to verify whether your antidetect browser handles partitioned storage correctly.

Test 1: Partition Key Format

Open Chrome DevTools in your profile. Navigate to a page with third-party embeds that set partitioned cookies (many ad-supported sites work). Go to Application → Cookies.

Look for cookies with the Partition Key column populated. The format should be https://example.com (the top-level site's origin).

What to check:

Is the partition key present at all? If missing, your browser might not support CHIPS.
Does the format match real Chrome? Should be https:// + eTLD+1 of the top-level document.
Is it consistent across reloads? Random or changing partition keys are a red flag.

Test 2: Cross-Profile Isolation

This requires two profiles. Let's call them Profile A and Profile B.

In Profile A, visit site-one.com (any site with third-party tracking embeds)
Note the partitioned cookies set by any third-party domain
In Profile B, visit site-two.com with the same third-party embed
Check if Profile B can "see" the partitioned cookies from Profile A

It shouldn't. If it can, your profiles are sharing underlying storage.

But here's the subtler test:

In Profile B, visit site-one.com (same top-level as step 1)
Check the third-party's partitioned cookies

Even though both profiles visited the same top-level site, they should have different partitioned storage. If Profile B somehow has access to Profile A's partition, your profile isolation is broken at the engine level.

Test 3: IndexedDB Partitioning

Same concept, different storage:

Visit a site that uses third-party IndexedDB (financial embeds, identity widgets)
DevTools → Application → IndexedDB
Look for databases scoped to third-party origins
Note their contents
Switch profiles and repeat

Each profile should show independent IndexedDB instances. Shared IndexedDB across profiles is a critical isolation failure.

For ad verification workflows, this kind of storage leak can expose that you're running multiple verification checks from the "same" browser, even with different fingerprints.

Step 5: How Native Engine Control Fixes This

Extension-based antidetect browsers have a fundamental problem: they can't control partition key generation. The partition key is computed deep in Chromium's storage layer — in C++ code that runs before any JavaScript executes. Extensions operate in the JS sandbox. They can override what a page sees, but they can't change how the browser internally generates partition keys.

This means extension-based tools either:

Pass through Chrome's native partition keys (fine for privacy, but all profiles share the same partition behavior)
Don't handle partitioning at all (third-party cookies work like pre-CHIPS, which is itself detectable)

Neither option is great. I'm being diplomatic here — the second option is actively bad.

Native antidetect browsers — the ones that fork Chromium and run each identity as its own browser process — keep partitioned storage genuinely separate. JustBrowser's Chromium engine leaves Chrome's partition-key logic untouched, and each profile runs in its own user-data directory, so partitioned cookies and storage never cross profiles. The partitioned storage for example.com in Profile A is independent from the partitioned storage for example.com in Profile B.

The difference isn't just isolation. It's authenticity. A partition key that looks wrong — wrong format, wrong origin scheme, wrong escaping — is a detection signal. Native engine control means the partition key implementation matches real Chrome bit-for-bit, because it is unmodified upstream code — isolation comes from separate profile directories, not a rewritten storage layer.

(This is also why the native engine isn't a premium add-on here — it's the whole product. There's one plan at $9.99/mo, per-profile storage isolation included, and the seven-day trial withholds none of it.)

Common Errors and Fixes

No Partition Key column in DevTools cookies: Your browser may not support CHIPS, or the site isn't using partitioned cookies. Test on Google embeds. Check chrome://version — you need Chromium 114+ for CHIPS, 127+ for full enforcement.

Same partition key hash across profiles: Your antidetect browser shares partition key generation logic without per-profile isolation. This is architectural — switch to a native-engine browser. Can't be patched via config.

Third-party cookies working cross-site: Your browser has CHIPS disabled or uses an older Chromium fork. If on a recent version but seeing cross-site cookie access, the antidetect may have disabled partitioning for "compatibility."

Partitioned storage persists after profile clear: Some browsers don't include partitioned storage in "clear profile." Manually clear via DevTools → Application → Storage → Clear site data. If it still persists, file a bug.

Assuming "separate cookies" means "separate partitions": You can have isolated cookie jars while sharing partition key metadata. The key format and storage structure are observable signals beyond cookies themselves.

Testing only on legacy sites: Many sites haven't adopted CHIPS yet. Test on sites with Google Analytics, Google Ads, or Meta pixels — those are CHIPS-aware.

Next Steps

Storage partitioning is one layer of profile isolation. For complete safety: run the CreepJS test on every profile, match timezone/geolocation to proxy, and test each profile before production use.

For scraping teams, the Playwright/Puppeteer integration guide covers connecting via REST API with partition isolation intact. For ad verification, pair with ClickzProtect to analyze traffic quality. For your own funnel tracking without fingerprinting signals, JustAnalytics provides privacy-first analytics.

CHIPS rolled out this year. More partitioning changes are coming — probably Storage Access API changes in late 2026 if I had to guess, though Chrome's deprecation timeline has been... flexible.

The teams who get reliable results understand these internals. Not just which buttons to click, but why the buttons exist. Partition keys aren't exciting. They're not something you'd brag about understanding at a party. But they're the detail that separates profiles that stay isolated from profiles that leak.

Frequently Asked Questions

CHIPS (Cookies Having Independent Partitioned State) creates separate cookie jars for each top-level site. A third-party embed on example.com gets a different cookie than the same embed on another-site.com — even with the same domain. This prevents cross-site tracking through embedded content but changes how separate profiles share or isolate third-party state.

Does storage partitioning affect my antidetect browser profiles?

Yes. Chrome's Storage Partitioning extends beyond cookies to localStorage, IndexedDB, Cache API, and SharedWorkers. Each storage type is now keyed by the top-level site. Antidetect browsers need to handle partition keys correctly to prevent cross-profile leakage. Native engine browsers can control partition key generation at the C++ level, while extension-based tools may leak partition data across profiles.

How do I verify my profiles handle partitioned storage correctly?

Visit a site with embedded third-party content in Profile A, then visit a different top-level site with the same embed in Profile B. Check if the third-party storage differs. Tools like BrowserLeaks Storage Test can reveal shared partition keys. If both profiles show identical partitioned storage from different top-level contexts, your profile isolation is compromised.

Can partitioned cookies be used for fingerprinting?

Partition keys themselves can become a fingerprinting vector. If your browser generates unique or unusual partition key formats, that metadata leaks identity. Native antidetect browsers generate partition keys matching real Chrome behavior. Inconsistent partition key formats — or missing partitioning entirely — flag profiles as spoofed or automated.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. C++ engine patches at the canvas / WebGL / audio / font / screen layer, so 40+ identity parameters are genuine, not faked. REST API for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower