What is a browser session?

The terminology around "session," "context," and "tab" gets sloppy fast — vendors mean different things by each. The clean working definition: a browser session is one isolated browser instance, with its own state, its own network identity, and its own lifecycle. In Notte's SDK and most cloud-browser products, the session is the unit of work — with client.Session() as session: ... — and everything that lives inside it (tabs, navigations, actions) inherits its isolation. Other tools (Playwright especially) use "session" to mean something narrower; reading those docs requires a quick translation.

What's actually inside a session

A modern browser session bundles five things into one isolated unit:

A browser process (or microVM, or container, depending on the platform's isolation model).
Cookies, localStorage, sessionStorage, IndexedDB — the storage classes that carry authenticated state.
Cache (HTTP cache, Service Worker caches).
A network identity — the IP / proxy the session exits through, plus the fingerprint surface (user agent, canvas hash, fonts, timezone).
A lifecycle — the session starts when you open it and ends when you close it (or hit a timeout). Browser state can be persisted to a profile on close.

The session is the boundary across which isolation is guaranteed. Within one session, multiple tabs share state; across two sessions, nothing is shared.

Session vs. context vs. tab

These three terms get conflated; they aren't the same:

Tab — one page within a session. Tabs share storage with the session that owns them.
Browser context — a Playwright concept: a sub-isolation inside one Chromium process. Two contexts share the binary but not the cookies. Playwright uses this for parallel test isolation cheaply.
Browser session — the full isolated unit. In cloud-browser platforms, every session is its own browser process (or microVM); contexts inside it are an optimization.

	Tab	Browser context (Playwright)	Browser session
Storage isolation from peers	None	Yes	Yes
Process boundary	No	No (shared Chromium)	Yes (own process / VM)
Network identity	Inherits session	Inherits parent	Own
Multi-tenant safety	Unsafe	Risky (shared kernel)	Safe (microVM / container)
Cost	Cheapest	Cheap	Higher
Best for	Parallel pages within one user	Parallel tests within one suite	Per-customer isolation, real workflows

For agent products, the right unit is almost always the session, not the context. Cross-tenant data must not leak; in-process Playwright contexts can leak under attacker pressure or kernel exploits. Sessions enforce isolation at a layer that's harder to break.

Notte SDK shape

main.py

from notte_sdk import NotteClient

client = NotteClient()

# Open a session; it's the unit of isolated work.
with client.Session(
    proxies=True,
    solve_captchas=True,
) as session:
    session.execute(type="goto", url="https://example.com")
    snapshot = session.observe()
    print(snapshot.metadata.title)

# Outside the context manager, the session is closed; state is gone unless
# attached to a persistent profile.

The session-as-context-manager pattern is the SDK default: open, do work, close — clean lifecycle. For long-running sessions (hours, sometimes), the context manager extends; for ephemeral ones (the serverless browser shape), teardown is automatic.

Persisting session state

A naive session is ephemeral: open, work, close, state gone. The two layers that survive across runs:

Browser profile. Save cookies, storage, cache to a profile so the next session starts already authenticated. See what is a browser profile.
Session persistence. The broader concept covering every storage class that should survive — see session persistence for browser agents.

Reach for a profile when you want authenticated state to persist (typical for agent workflows on user accounts). Don't try to roll your own cookie-pickling — modern apps put auth in localStorage that simple cookie persistence doesn't capture.

Common pitfalls

Treating one Playwright context as equivalent to a session. It isn't, for multi-tenant work. Same kernel, same Chromium binary — exploits or state bugs leak across contexts. Use real sessions per tenant.
Closing the session prematurely. Sometimes the workflow needs to continue across what looks like a logical boundary. Keep the session open until the task is done.
Reusing a session across users. Per-user isolation requires per-user sessions (or per-user profiles attached to fresh sessions).

Key takeaways

A browser session is one isolated browser instance — process / microVM, cookies, storage, network identity, lifecycle — and the unit of work in cloud-browser SDKs.
Distinct from a Playwright "context" (cheaper but shared-kernel) and from a "tab" (no isolation at all).
Per-tenant work needs real sessions; in-process contexts aren't safe for multi-tenant isolation.
Pair with browser profiles to persist authenticated state across sessions.

What is a browser session?