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

Picture this: you've set up separate profiles for separate clients, each with its own proxy and its own cookie jar. You expect them to be fully independent. But cookies are only one of the places a browser keeps state.

Since Chrome introduced CHIPS and storage partitioning, third-party state is also keyed by the top-level site. That is a privacy improvement, and it also changes what "isolated" means for a set of profiles.

Browser privacy features are designed to prevent cross-site tracking. If a tool that manages many profiles implements them differently from Chrome, or shares storage underneath, the gap can blur the boundary between profiles. 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:

1. What CHIPS (Cookies Having Independent Partitioned State) actually does
2. How Chrome's broader Storage Partitioning affects localStorage, IndexedDB, and more
3. Why this matters for profile isolation
4. How to test whether your profiles handle partitioning correctly
5. 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." It's for people who need to understand the internals.

Prerequisites

• A multi-account 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 cannot be read by tracker.com when it is embedded 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 (current Chrome)
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 partitioning is now part of how the browser stores state, and a profile that handles it differently from Chrome, or shares it with other profiles, isn't as separate as it looks.

Step 2: Why Partition Keys Matter for Profile Isolation

When you run multiple 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 browser doesn't properly isolate storage per profile, your profiles can share partitioning behavior. Which means:

1. Partitioning that differs from Chrome. If a browser computes partition keys differently from Chrome, or drops a component, embedded content behaves differently than it does for Chrome users, and anything you test in that profile stops reflecting what your visitors see.

2. Cross-profile partition data bleeding. Some tools share underlying storage between profiles at the engine level and only separate things at the JavaScript layer. Partitioned storage can bypass those JS-level barriers.

3. 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, and embedded features built around partitioned cookies won't behave the way they do in current Chrome.

It's easy to assume profile isolation means cookie isolation. It doesn't. Not anymore.

In 2026, profile isolation means partition isolation as well. That matters for privacy, for QA and testing, and for teams keeping client profiles separate: you want each profile's partitioned storage to be independent of every other profile's.

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.

A typical case: 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 browser doesn't handle partitioned IndexedDB correctly, identifiers can carry across contexts or fail to persist where they should.

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 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.

1. In Profile A, visit site-one.com (any site with third-party tracking embeds)
2. Note the partitioned cookies set by any third-party domain
3. In Profile B, visit site-two.com with the same third-party embed
4. 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:

5. In Profile B, visit site-one.com (same top-level as step 1)
6. 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:

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

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

For ad verification work, a storage leak between profiles would mix results that are supposed to be independent.

Step 5: Where the Engine Matters

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 change what a page sees, but not how the browser stores partitioned state underneath.

So a tool that separates profiles only at the JavaScript layer, inside one shared browser, can't separate partitioned storage. And a tool that switches partitioning off "for compatibility" falls back to pre-CHIPS behaviour, which differs from current Chrome.

What keeps partitioned storage separate is architecture: each profile running as its own browser, with its own user-data directory. JustBrowser's Chromium engine works that way and leaves Chrome's partition-key logic untouched, 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 fidelity. Because the partition logic stays Chrome's own, embedded content behaves the way it does in Chrome, so what you test in a profile is what Chrome users get. 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. Partitioned cookies shipped in Chrome 114, so anything older won't have them.

Same partitioned data visible across profiles: Your tool shares storage between profiles without per-profile isolation. This is architectural — switch to a browser that gives every profile its own user-data directory. It can't be fixed with a setting.

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 tool 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 other partitioned storage underneath. Check IndexedDB and the other storage types too, not only cookies.

Testing only on legacy sites: Many sites haven't adopted CHIPS yet. Test on pages with third-party embeds from large providers, which are more likely to set partitioned cookies, and confirm in DevTools that the Partition Key column is populated.

Next Steps

Storage partitioning is one layer of profile isolation. To keep profiles clean: read the JA4 and TLS fingerprint explainer to see what the network layer reveals, match timezone and geolocation to the proxy, and test each profile before real use.

For teams automating their own workflows, the Playwright/Puppeteer integration guide covers connecting via the local 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.

More partitioning changes will likely follow, though Chrome's third-party cookie 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, but they are one of the details that separates profiles that stay isolated from profiles that leak.

Frequently Asked Questions

What is CHIPS and how does it change cookie behavior?

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 multi-account 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. A multi-account browser needs to keep partitioned storage separate between profiles. Browsers with a native engine and a separate user-data directory per profile keep partitioned storage apart by design, while extension-based tools may share 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. If both profiles show identical partitioned storage from different top-level contexts, your profile isolation is compromised.

Can partitioned cookies be used for fingerprinting?

CHIPS exists to reduce cross-site tracking, not to add to it. The risk for profiles is a browser that handles partitioning differently from Chrome: with partitioning missing, embeds can follow you across sites, and with non-standard partition logic, embedded content behaves differently from Chrome, which undermines any test you run in that profile. A browser that keeps Chrome's own partition-key logic behaves the way Chrome does.

---

Try JustBrowser

A multi-account browser for teams, built on a custom Chromium engine with native C++ integration, not an extension. Each profile is its own browser with its own cookies, storage, proxy and 40+ identity parameters, and teammates can share profiles. Local REST API and CDP for Playwright, Puppeteer, Selenium. Windows x64 and macOS (Apple Silicon). $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