Import and Export Cookies Between Browsers

Moving a logged-in session from one browser, profile or machine to another is a routine developer task: reproduce a bug in a clean profile, hand a QA colleague a working session, or give a scraper the same cookies your browser has. It is also the operation where cookies most often arrive looking correct and refusing to work. Here is the reliable version, and the reasons for the failures.

Pick the format before you export

Everything except JSON loses information. cookies.txt has no SameSite field; a header string has no attributes at all. If the target needs a working session rather than a single request, export JSON.

Export from the source browser

1. Open the site you are logged into and click the CookieMan icon.
2. Choose Export.
3. Set the scope: current site for one app, or all cookies when migrating a whole profile.
4. Pick JSON Array and download the file (or copy it to the clipboard).

Scope matters more than it looks. "All cookies" is convenient for a profile move and reckless for a bug report — it includes every session you have open. Prefer per-site exports when the file leaves your machine at all.

Import into the target browser

1. Install CookieMan in the target browser — Chrome, Edge or another Chromium build.
2. Open the destination site first. Cookies are written per domain, and starting on the right origin avoids surprises with host-only entries.
3. Click Import and paste the exported data. The format is detected for you.
4. Check the preview — names, domains and flags — then Apply.
5. Reload the page. If the session took, you are logged in.

Going the other way, from a file a tool produced, the online converter will normalise it into JSON first if the import complains. Playwright dumps are a wrapped storageState object — unwrap them here. Puppeteer page.cookies() is a bare array — convert that instead. If SameSite must survive, do not pass through Netscape: JSON Array vs cookies.txt.

Why a transferred session sometimes refuses to work

When the cookies are visibly present and the site still logs you out, the cause is almost always one of these:

• The server binds the session to more than the cookie. IP address, user agent or a device fingerprint. Nothing you do client-side fixes this — it is the site's design.
• Host-only versus domain cookies. A cookie with no Domain attribute is not sent to subdomains. Re-importing it as .example.com, or the reverse, changes who receives it.
• __Host- and __Secure- prefixes. These names are only accepted under strict conditions — Secure, Path=/, and for __Host- no Domain. Break one and the browser rejects the cookie silently.
• Partitioned (CHIPS) cookies. A partitioned cookie belongs to a top-level site as well as its own domain. Imported into a different partition, it is simply not sent.
• Session cookies that expired in transit. Expiry 0 means "until the browser closes" — some exports drop them entirely.
• HTTP versus HTTPS. Secure cookies will not be stored for a plain-HTTP origin, so a localhost test over HTTP quietly loses them.

Read the attribute rules once and these stop being mysteries.

Handle the file like a credential

An exported session cookie is a bearer token: whoever has it is you, until it expires or the server revokes it. So —

• Never paste an export into a ticket, chat channel or shared document.
• Delete the file when the task is done; log out afterwards to invalidate the session server-side.
• Prefer a per-site export over "all cookies".
• Be wary of any online cookie tool that uploads your data. Ours does not — the conversion runs in your browser, and the extension has no network code at all.

Full details of what the extension can read and write are on the features page, and the permission-by-permission rationale is in the privacy policy.