What real cookie isolation is, and why it matters for multi-accounting
Plenty of extensions market themselves as "multi-login" or "lightweight antidetect" tools, but most only change the UI or use a fake container — the underlying cookies are still shared, just labeled differently. AxioSession works at the network-request layer instead: it genuinely prevents two tabs from sharing cookies, even when both have the same website open.
⚡ Key takeaways
- ✓ "Real" isolation means intercepting the actual HTTP Cookie/Set-Cookie headers of every request, not just swapping a theme or display name.
- ✓ AxioSession uses declarativeNetRequest (Chrome's own Manifest V3 API) to rewrite the Cookie header per (tabId, hostname) pair.
- ✓ Real Set-Cookie values from the server are captured via webRequest before they get stripped, then stored in that session's own "cookie jar".
- ✓ localStorage is isolated the same way, by prefixing keys, running in the page's own MAIN-world JavaScript context.
Table of contents
The real mechanism: rewriting the Cookie header per tab
When you open a page in a tab that belongs to a non-default session, AxioSession registers a declarativeNetRequest rule scoped to that exact tabId and hostname. The rule does two things: it overwrites the outgoing Cookie header with the value stored in that session's isolated jar, and it strips the incoming Set-Cookie header so the browser's single shared cookie store never gets polluted.
In parallel, a webRequest.onHeadersReceived listener captures the real Set-Cookie value from the network response — before the rule above strips it — and writes it into the correct isolated jar. So when a site sets a new login cookie (after you click Log in, for example), it lands in the right place instead of the shared cookie pool.
How is this different from "container" or "fingerprint swap" extensions?
Many extensions only change a few JavaScript-readable values (User-Agent, screen resolution...) while login cookies remain shared by the browser — open two tabs at once and you still get logged out of each other, because cookies keep overwriting one another.
Real containers (like Firefox's Multi-Account Containers) do isolate cookies, but Chrome has no equivalent public API for third-party extensions — which is exactly why AxioSession had to build its own isolation engine on top of declarativeNetRequest instead of relying on a ready-made container API.
Want to try it yourself right now?
Your first 3 sessions are free forever, no credit card required.
localStorage is isolated too, not just cookies
Many modern sites (Shopee Seller Center in particular) store part of the login state in localStorage, not just cookies. AxioSession injects a content script that runs in the page's own "MAIN world" (the same JavaScript context as the site itself) to wrap localStorage.getItem/setItem, automatically prefixing keys by session ID — each session reads and writes its own slice of localStorage without colliding with another.
Frequently asked questions
Does this slow down pages? ↓
Not noticeably. declarativeNetRequest runs at Chrome's native layer (no JavaScript round trip per request), so the added latency is effectively imperceptible.
What are the limits of this mechanism? ↓
A background request (XHR/iframe) to a completely different domain within the same page load (not a full navigation) may not get isolated if that domain was never directly navigated to. Normal login/usage flows on Facebook, Shopee, and TikTok still work correctly because they rely on cookies set on their own primary domain.
AxioSession Engineering Team
The team that built AxioSession's cookie isolation engine on top of Chrome's declarativeNetRequest API.
