SessionCourier install now ↗

guides

Import and export cookies

Move cookies between browsers and tools — JSON round-trips, Netscape cookies.txt for curl, wget and yt-dlp, and a ready-to-run curl command.

JSON

The JSON export is the full-fidelity, browser-to-browser format: every cookie attribute is preserved in Chrome’s native cookie shape, so nothing is lost on the round trip. Export the cookies on machine A, import the file on machine B, and you have the same session there.

Use JSON when the other end is a browser (yours or a teammate’s). If the other end is a Playwright or Puppeteer test, use the storageState export instead — its cookie shape is what those tools expect, and the plain JSON export is not. The precise field layout of each format is documented in the export formats reference.

Netscape cookies.txt

cookies.txt is the classic tab-separated format that command-line tools have read for decades. Export it from SessionCourier and hand it straight to curl, wget, or yt-dlp:

curl -b cookies.txt https://staging.example.com/api/me
wget --load-cookies cookies.txt https://staging.example.com/report.pdf
yt-dlp --cookies cookies.txt "https://example.com/members-only-video"

The file itself is one cookie per line, seven tab-separated fields. A leading #HttpOnly_ on the domain marks an HttpOnly cookie:

# Netscape HTTP Cookie File
.staging.example.com	TRUE	/	TRUE	1789430400	session	abc123
#HttpOnly_.staging.example.com	TRUE	/	TRUE	1789430400	refresh_token	xyz789

curl command

For a one-off API call, export a runnable curl command — the current cookies replayed against the site as one literal Cookie header, ready to paste into a shell:

curl 'https://staging.example.com/' -H 'Cookie: session=abc123; refresh_token=xyz789'

The command targets https:// when any cookie is Secure, otherwise http://; exporting the all-sites view emits one command per host. It carries cookie values only — no domain, path, expiry, or flags — so it’s best for quick, short-lived requests rather than persisting a session.

Importing

Open the import menu and either paste the text or pick a file (.json or .txt); SessionCourier detects which format it is and writes each cookie into the active tab’s cookie store. Everything it exports round-trips back in — JSON, Playwright storageState, Netscape cookies.txt, and a pasted Cookie: header string — with one exception: the curl command is a shell command rather than a store, so it is export-only.

Import merges into the current store: it overwrites any existing cookie with the same name, domain, and path (last write wins) and leaves the rest untouched. Import into the browser profile you intend to change — a snapshot from one account overwrites the matching cookies of whatever account is currently logged in.

Restoring localStorage when the site redirects to a login

Only the storageState format carries localStorage, in its origins array, and the two halves of such a file restore under different rules:

  • Cookies are written through the browser’s cookie API, which addresses them by domain. No particular page needs to be open — they land whatever the active tab happens to be showing.
  • localStorage is origin-scoped and reachable only from a live document of its own origin, so it can only be written into a tab already at rest on the origin the file names.

That difference only becomes visible when a site sends you somewhere else before you can settle on it — and whether it matters depends on where it sends you.

A same-origin login redirect is not a problem, and needs no workaround. If app.example.com bounces you to app.example.com/login, the tab never leaves the origin, so the restore works normally. Only the origin counts here; the path is irrelevant. This surprises people, so it is worth stating plainly: a redirect you can see in the address bar does not necessarily break anything.

A cross-origin redirect is the one that bites. If app.example.com hands you to an identity provider at login.example.net, the tab comes to rest off-origin and nothing is restored. SessionCourier says so rather than failing quietly, naming the origin your tab is actually on — “The active tab is on https://login.example.net, so the 1 localStorage entry for https://app.example.com was not imported…” There are two ways out, and which one applies depends on whether the file carries cookies.

If the file carries cookies: import it twice

  1. Import once. The cookies land regardless of which page is open — including the identity provider’s.
  2. Return to the app and reload. With its session cookies now in place it no longer bounces you to the login, so the tab finally rests on the app’s own origin.
  3. Import the same file again. This pass finds the tab on the matching origin and offers the localStorage restore, naming the keys before it writes them.
  4. Reload once more if the app doesn’t pick the token up — most apps read localStorage only at page load.

If the file’s cookies array is empty: park the tab on the origin first

A single-page app that keeps its entire session in a localStorage token exports cookies: [], and then importing twice cannot work — there are no cookies for pass one to place, so nothing stops the redirect.

Open any URL on that origin that does not redirect, and import from there:

https://app.example.com/robots.txt
https://app.example.com/favicon.ico
https://app.example.com/no-such-path

A 404 page serves as well as a real one. localStorage belongs to the origin, not to the document that happens to be open, so writing it from /robots.txt puts the token exactly where the app will look for it. Import there, then navigate to the app — it loads already authenticated.

One notice to tell apart from these two: if SessionCourier asks you to grant it access to the site instead of naming the origin your tab is on, then it could not read the tab’s URL at all. That is a permissions matter, not a redirect — moving the tab will not help until access is granted.