Skip to main content
This guide creates a profile, writes browser state to it, and reuses the saved state in a later browser session.

1. Create a profile

Give the profile a meaningful name that is unique within your project.

2. Start a writer browser

Attach the profile by name or id. Set save_changes to true only when this browser owns writes to the profile.
Before starting more than one writer, read Sharing and concurrency. Profile saves replace the complete stored snapshot and don’t merge concurrent changes.

3. Use and delete the browser

Navigate, authenticate, or complete the part of the workflow whose state you want to retain. Then delete the Kernel browser to save the state. To save without ending the browser, see Save a running browser to a profile.
Calling browser.close() only closes the Playwright connection. It doesn’t save the profile. You must delete the Kernel browser or let it time out.

4. Load the saved state

Create another browser with the same profile. Omit save_changes to keep the stored profile unchanged during this run.

Save a running browser to a profile

You can save a running browser’s current state to a profile without deleting the browser. Send POST /browsers/{id_or_name}/profiles with either:
  • id to overwrite an existing profile, or
  • name to overwrite the profile with that name in the browser’s project, or create it when it doesn’t exist.
The response is the saved profile. It returns 201 when the request created the profile and 200 when it overwrote one.
Saving copies the browser’s data while Chromium is stopped, restarts Chromium, then uploads the copy. The request returns once the restarted browser accepts CDP connections again and the profile is stored. Large profiles can take longer than the TypeScript and Python SDKs’ default one-minute timeout, so the examples above set five minutes. A longer timeout also stops the SDK from retrying a slow save that is still running.

What restarting the browser means for your automation

  • Connections close. Existing CDP, Playwright, Puppeteer and WebDriver connections disconnect. Reconnect to the browser’s cdp_ws_url after the request returns, and create a new WebDriver session.
  • Pages reload. Open tabs are restored, but each page reloads. In-page state that wasn’t persisted, such as JavaScript variables, unsent form input, and in-flight requests, is lost.
Call the endpoint at a stable point in your workflow, for example right after a login completes, rather than while a page is mid-action. The browser keeps the same session ID and connection URLs.

What’s saved

The saved profile contains the same state as a profile saved when the browser is deleted: cookies, local storage and other site data, open tabs, and preferences. Data that’s large or that Chromium can rebuild is left out, including caches, service worker registrations and their storage, and some large offline storage that web apps keep. That data stays in the running browser; it’s only left out of the saved profile. Saving doesn’t attach the profile to the browser or change the browser’s save_changes setting. Other browsers already using the profile keep the state they loaded, and new browsers get the saved state the next time they load the profile.

Overlapping saves

When saves to the same profile overlap, the save that started most recently wins, even if an earlier one finishes after it. If the profile is also attached to a browser with save_changes: true, the save made when that browser is deleted replaces the stored profile with that browser’s state.

Inactivity timeout

A successful save counts as activity: it restarts the browser’s inactivity timeout. A failed save leaves the timeout unchanged.

Errors

A failed save never stores a partial or corrupt profile. When a name request created a new profile and the save was rejected with a 409, that empty profile is removed so the name stays free.

Control the starting tab

By default, a profile restores its saved tabs. Pass start_url to discard those restored tabs and open a specific page when the browser starts.
The same behavior applies to browser pools configured with both a profile and a start URL.
Managed Auth controls the tab state of profiles attached to auth connections. Each login or automatic reauthentication starts with one tab at the configured login URL, or at the domain homepage when no login URL is configured. Successful authentication saves the resulting tab state. Failed and canceled sessions leave the profile unchanged.Set start_url when you create a browser if your automation requires a specific first page.

Load a profile after browser creation

You can attach a profile to a running browser that was created without one. Loading the profile restarts Chromium, so reconnect your CDP or Playwright client afterward.
You can’t load a profile into a browser that already has one. The browser must have been created without a profile configuration.
Loading a profile this way restores all of its saved tabs, which can leave the browser with several tabs open at once. Pass start_url in the same update() call to collapse those restored tabs down to a single tab at the page you specify.

Rename and manage profiles

Renaming a profile doesn’t recreate or change its stored state. The new name must be unique within the project.
Use the Profiles API reference or CLI reference to list, inspect, download, rename, and delete profiles.