Skip to main content
Contexts allow you to persist user data across multiple browser sessions, enabling smoother automation, seamless authentication, and faster end-to-end workflows. By default, each Browserbase session starts with a fresh user data directory, so cookies and application data reset between sessions. With Contexts, you can reuse this data across sessions, making automation workflows more reliable and eliminating repeated logins. Browser cookies are stored in the user data directory. Contexts are configured by:
  1. Creating a Context via the Contexts API
  2. Passing the Context ID into the Create Sessions API
View or run the example template here

Why use Contexts?

  • Reusing cookies & session data: Maintain login states across multiple sessions without needing to log in repeatedly.
  • Preserving authentication: Store and reuse authentication tokens, reducing the need to re-enter credentials.
  • Retaining application data: Persist localStorage, IndexedDB, and other site-specific data written by web applications.
  • Faster workflows: Skip login flows and re-authentication steps, reducing the total time of your automation runs.
A Context persists the contents of the Chromium user data directory, including:
  • Cookies: session cookies, explicitly backed up and restored between sessions
  • localStorage: per-origin key-value storage
  • IndexedDB: structured client-side databases
  • Session Storage: tab-scoped storage
  • Service Workers: site-controlled caching and offline support
  • Web Data: form autofill entries and saved form data
  • Browser preferences: site-level settings, permissions, and security state (e.g., HSTS)
Contexts don’t include the browser’s HTTP cache (images, CSS, JS, fonts). Each session fetches page assets fresh from the network. However, sites that use Service Workers to cache assets can see improved page load times, since the Service Worker and its cache are persisted across sessions.
Context data can include stored credentials and other sensitive browsing data. Because of this, Contexts are uniquely encrypted at rest to ensure security.

Create a Context

To create a Context, use the Create Context API. This returns a unique Context ID that you can pass into new sessions to persist data. You can optionally set a name to label the Context. Names are unique within a project (compared case-insensitively), and leading or trailing whitespace is trimmed.

Use a Context

After creating a Context, use it in a new session to reuse cookies, authentication, and application data. This creates a returning user experience, speeding up your workflow and eliminating repeated logins.
After closing a session with persist: true, wait a few seconds before reusing the Context to ensure data is synchronized.
Here’s an example of how to use a Context in a new session, this example uses the Context ID from the previous example.

Set persist

If you need to store new cookies, authentication tokens, or application data, you must set persist: true when creating a session. This ensures that any changes made during the session (such as logging in or saving site preferences) are retained for future sessions instead of being lost when the session ends. The data will be saved when the session closes. persist: false prevents changes from being saved to the Context. It’s useful for less common use cases, such as:
  • Read-only session: If you need to access saved cookies or data without modifying them.
  • Prevent session state changes: Avoids overwriting stored login tokens or user data.
Need to combine cookies from separate Contexts? Follow Merge Contexts for a Stagehand v4 example and concurrency limits. This recipe copies cookies; it does not merge the full browser profile.

Login workflow

A typical flow to persist a website login across Browserbase sessions would be as follows:
  1. Create a Context (get a contextId).
  2. Start a first Browserbase session with that contextId and persist: true.
  3. Log in to a website inside this first session, either manually through the live view feature or programmatically.
  4. End this session.
  5. Wait a few seconds to ensure that the Context is updated.
  6. Start a second Browserbase session (and future sessions) with the same contextId and visit the same website. You should now be signed in automatically without having to repeat the login process.

Login best practices

Browserbase Contexts don’t expire (see Context expiration), but sites can still force a log out. Here are a few additional best practices:
  • Avoid simultaneous logins: Avoid having multiple sessions using the same Context at once. Sites may force a log out.
  • One Context per site, per login: Prevent an individual Context from becoming too large, which can slow down your session.

Context expiration

Contexts live indefinitely on Browserbase’s infrastructure. Once created, a Context persists until you explicitly delete it or it becomes invalidated. You can create a Context once and reuse it across sessions for weeks or months. However, there are several ways a Context can become invalid or unusable:

Client-side invalidation

  • Explicit deletion: Calling the Delete Context API permanently removes the Context
  • Project deletion: If the parent project is deleted, all associated Contexts are removed
  • Account changes: Account suspension or deletion will invalidate all Contexts

Application-level invalidation

While the context itself persists, the data stored within it can become stale or invalid due to external factors:
  • Session expiration: Websites may expire authentication cookies after a set period (e.g., 30 days), requiring re-authentication even with a persisted Context
  • Password changes: If you change your password on a website, stored session cookies may be invalidated by that website
  • Server-side logout: Websites can invalidate sessions server-side (e.g., “log out of all devices”)
  • Token revocation: OAuth tokens or API keys stored in cookies may be revoked by the service provider
  • Security events: Websites may force re-authentication after detecting suspicious activity
To handle application-level invalidation, implement checks in your automation to detect logged-out states and re-authenticate when necessary.

Merge Contexts

Combine logins from two saved Contexts into a new Context using Stagehand v4. For example, if Context A contains cookies for one site and Context B contains cookies for another, you can copy both sets into Context C. The source Contexts remain unchanged.

Read cookies from the source Contexts

Start one temporary reader session with Context A and another with Context B, both with persist: false so they do not save changes to the source Contexts. See Use a Context for session creation. Create these sessions with the Stagehand extension installed, for example with browserbase.launch. If you use the Browserbase SDK to create them instead, include the uploaded Stagehand extension when creating each session. browserbase.connect cannot add the extension to an existing session. Connect to these running sessions with browserbase.connect. Use their session IDs, rather than their Context IDs:
Node.js Connect to the source sessions
Attach Stagehand to each browser before reading its cookies, then close the temporary reader sessions. Avoid login or other cookie-changing activity in either session while collecting them.
Node.js Read source cookies
Build a combined list using the fields accepted by addCookies. A cookie’s domain, path, and name identify it: the example keeps identical duplicates once and rejects conflicting values or attributes. Resolve conflicts before continuing, especially when both sites use the same login provider. Keep leading dots in domains because they can indicate different cookie scopes.
Node.js Merge cookies

Save to a fresh Context

Create Context C, then start a Stagehand-enabled session using it with persist: true. Use one writer for this destination Context. See Create a Context and Use a Context for those steps. Connect to that session as sessionC, add the combined cookies, and close it to save them to Context C:
Node.js Save merged cookies
Wait a few seconds for persistence, then open a fresh session using Context C with persist: false and verify that both sites recognize the expected login. If either check fails, stop and inspect the saved state before adopting Context C. Sessions that are already running do not reload these cookies automatically.
This workflow copies unpartitioned cookies only. It does not copy localStorage, IndexedDB, or other browser profile data. Sites that require additional authentication state may still need a login.

Delete a Context

When you no longer need a Context, delete it using the Delete Context API. Once deleted, a Context can’t be used to create new sessions.
Deleting a Context is permanent and can’t be undone.

Handling authentication

Once you set up Contexts, follow the authentication guide to easily log into websites.

Manage browser sessions

Monitor session state and release browsers when work finishes.