1. Create a profile
Give the profile a meaningfulname that is unique within your project.
2. Start a writer browser
Attach the profile byname or id. Set save_changes to true only when this browser owns writes to the profile.
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.4. Load the saved state
Create another browser with the same profile. Omitsave_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. SendPOST /browsers/{id_or_name}/profiles with either:
idto overwrite an existing profile, ornameto overwrite the profile with that name in the browser’s project, or create it when it doesn’t exist.
201 when the request created the profile and 200 when it overwrote one.
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_urlafter 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.
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’ssave_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 withsave_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. Passstart_url to discard those restored tabs and open a specific page when the browser starts.
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.start_url in the same update() call to collapse those restored tabs down to a single tab at the page you specify.