Diese Seite gibt es noch nicht in Ihrer Sprache. Sie lesen den englischen Text.

Cookies in and out of a profile

A profile's whole cookie jar leaves as one file through Export cookies in the profile menu and goes back into another profile through Import cookies. You see two numbers, what arrived and what did not get in, and the file itself is live sign-ins.

Ten: Fields the app reads in your file
3: Ways an expiry may be spelled
One: Profiles per file
Arrived and refused: What you are told after import

What the file holds

You get one file of plain JSON: a list of records, one per cookie.

Each record carries the eight things below that decide where the cookie goes back and how long it lives there, and whatever else the engine gave with them. The import reads two more: a whole address, used in place of one built from the domain, and the session flag.

Name and value
The session token itself, and the name the site reads it by.
Domain and path
Which site gets the cookie back and which part of that site.
Secure and HttpOnly
Whether it travels only over an encrypted connection and whether page scripts may see it.
SameSite and expiry
Whether it goes along on a request begun at another site, and when it dies.

Which files will do

Import cookies in the profile menu takes JSON and Netscape, including exports from other antidetect browsers, Firefox records and the .txt that cookie extensions and curl write.

An expiry in milliseconds becomes seconds, a session mark does not wipe an expiry, and a cookie past its expiry is not loaded.

You take the whole jar

With Export cookies in the profile menu, the shipped build takes everything the profile holds rather than the cookies of the page in front of you. The number in the message is the number of records written to the file.

Where that jar sits is decided by the engine the app is set to, and so is whether the profile has to be open.

The file is named after the profile by default, with anything outside letters, digits, dot, dash and underscore replaced, and you choose where it goes.

The engine in the settings	Where the jar is	To read it or write it
ARMANOS Browser	Inside the running browser	The profile has to be running in that build
Built in engine	In the profile folder on disk	Open or closed, both work

You are told, not handed an empty file

With the setting on ARMANOS Browser you are asked to start a profile that build is not running, rather than handed an empty file, open or not. An empty file under a green message looks exactly like a profile with no session at all.

Export from the window, and clearing

Inside an open profile, Cmd+Shift+K on a Mac or Ctrl+Shift+K elsewhere exports its cookies straight to a file.

Clear cookies… in the profile menu deletes every cookie of a profile on this computer, and Clear cookies in the bar does it for a selection. Site data stays.

The file is a set of live sign-ins

Whoever opens that file can sign in as those accounts, so the app says it before the save dialog rather than after.

The file is held by permissions and not by a password. On macOS and Linux it goes to your account alone, and those permissions travel with the copy.

On Windows permissions are not what protects a file. There it takes the rights of the folder you saved it into.

Delete it once the move is done

A cookie file on a desktop or a memory stick is a working sign-in for as long as the session lives.

You see what did not arrive

A browser turns a cookie away for plenty of ordinary reasons, and one bare number of what arrived reads as a session moved in full.

So the message carries both numbers, and somebody the site still asks to sign in knows where to look.

Three of the reasons below are the app's own refusals and the last one comes from the browser, though the message counts them all as one number.

What the file had	What happens to it	Where it counts
No domain and no address	There is nowhere to send the cookie back to	Refused
No name	A record without a name is not a cookie	Refused
An expiry the browser cannot read	The date is dropped and the cookie still goes in	Arrived and refused both
A rule of the browser itself	Secure on a plain address, or a domain that does not match	Refused

Cookies do not carry the machine

A session is half of what keeps an account signed in. The other half is the device the site saw that session from.

A profile's number is the seed its fingerprint is derived from, and no cookie file carries that number.

A cookie file is the right tool when only the sign-ins have to move and the profile itself stays where it is.

A cookie file
The jar of one profile and nothing else.
A transfer file
The profile with its session and its number, closed with a password you choose.
Session in the folder
The same archive, carried by a cloud folder that is already yours.

Cookies inside a flow

The Cookies flow step works on the cookies of the profile it runs in, one cookie at a time.

The step reads cookies of the site it stands on while the tab holds a web page. On a blank or internal page it falls back to the domain you wrote on it.

Read cookie
One named cookie of the current site, into a variable.
Write cookie
One cookie written for the current site or for a domain you name.
Delete cookie
One named cookie removed.
Clear cookies of this site
Every cookie of the current site, and the step returns how many went.

What this does not do

Archives and files in neither JSON nor Netscape are not read.
You are not told which rule refused which cookie. The count is on screen and the detail behind it is not.
Into an existing profile, cookies go one profile at a time, with no load across a selection.
It does not sign you in by itself. A site weighs the device and the address too and can ask for the session again.

How to check

Every claim above sits in one file, and most have a stand you can run.

Export reads the whole jar, not the page in front of you: apps/desktop/src/lib/forkPage.js · apps/desktop/test/cookie-transfer.js
SameSite and the expiry reach the browser on import: apps/desktop/test/cookie-transfer.js
Import counts what was refused beside what arrived: apps/desktop/src/main/main.js
The cookie file is written for your account alone: apps/desktop/src/lib/secureFile.js · apps/desktop/test/secrets-on-disk.js
A flow reads a cookie only for the site its step stands on: apps/desktop/src/main/main.js · apps/desktop/test/rules-and-runs.js
Cookies over the API, open or closed profile: apps/desktop/test/api-куки.js · apps/desktop/test/api-куки-закрытого-живьём.js

Questions

Can I bring a file from another tool?: If it is an ordinary list of cookie records, yes. We read the fields a cookie has, not one product's own database.
Can a script read and load cookies?: Yes, through the local API, open or closed profile; the cookies stay on this computer.
Do the two numbers in the message add up?: Not always. A cookie whose date could not be read goes in without it and is counted on both sides, because a lost expiry is worth telling you about.
Will the account still be signed in after the move?: Often, though not always. The site weighs the machine and the address too, so a session arriving without its own fingerprint looks like a new device.

Take one session with you

In ARMANOS, open a profile and write its jar to a file you carry yourself.

Sign-ups paused for now Your session on two computers