Cookies, Local Storage and IndexedDB: What a Session Really Is
Signing in writes to three separate places. Knowing which is which explains why sessions survive some things, break on others, and why syncing a profile has to move all three.
"Being logged in" feels like one thing. It is at least three, stored in three different places with three different lifetimes, and the difference explains most of the confusing behaviour people run into when moving sessions between machines.
Cookies
Small key-value pairs, sent automatically with every request to the site that set them. This is where the session token usually lives.
- Scoped to a domain and path, with an expiry date.
- A `Secure` cookie is only sent over HTTPS; an `HttpOnly` cookie is invisible to page JavaScript.
- A session cookie has no expiry and is meant to disappear when the browser closes.
Cookies are the smallest of the three and the most load-bearing. Lose them and you are signed out.
Local Storage and Session Storage
String key-value storage, read and written by page JavaScript, scoped per origin. It is never sent with a request. The page has to read it deliberately.
Applications keep preferences, cached profile details, feature flags and often a refresh token here. Local Storage persists until it is cleared; Session Storage lasts only as long as the tab.
IndexedDB
A real database in the browser: structured records, indexes, transactions. This is where a modern web application keeps anything substantial: cached message histories, offline queues, encryption keys for end-to-end encrypted features.
Why this matters for a profile
It gives "isolation" a precise meaning. Two profiles are isolated when all three of these are separate, plus the cache and the extension state. A tool that isolates cookies and shares IndexedDB has isolated the easy third of the problem.
It also sets the bar for moving a profile between machines. Carrying cookies alone reproduces the shape of a session without its substance.
| Store | Written by | Typically holds |
|---|---|---|
| Cookies | Server and page script | Session token, preferences, tracking identifiers |
| Local Storage | Page script | Refresh tokens, UI state, cached profile details |
| Session Storage | Page script | Per-tab state, discarded when the tab closes |
| IndexedDB | Page script | Cached data, offline queues, encryption keys |
Moving a session between your own machines
PowerOps captures cookies, Local Storage and IndexedDB when a profile closes and restores them when it opens somewhere else. Each category is a switch, for the whole workspace or for a single profile, so you can move exactly as much as you intend to.
Two properties are worth knowing about how that works:
- The snapshot is encrypted on the machine it came from, with a key that belongs to the workspace, and decrypted on the machine that opens the profile. This is not end-to-end encryption: the service keeps a copy of that key so that your other computers can receive it.
- A profile is open on one machine at a time. While it is open it holds a lease, and another device is told which device has it rather than being allowed to fork the session into two divergent copies.
That second point is a deliberate limitation. Two machines editing one session independently produces two half-valid sessions and, quite often, a signed-out account on both. A cookie jar has no way to resolve a merge conflict.
The practical takeaway
Close profiles rather than killing them. The write-out on close is what makes the session portable, and it is the cheapest habit on this list.
PowerOps
