Start with what is actually being transferred
An account handover is not just a set of files or credentials. It is a transfer of access to a platform account, and the delivery format affects what the buyer can use, what remains under the seller’s control and what may stop working. A login and password, a browser cookie, an access token and a browser profile archive are not interchangeable ways of packaging the same thing.
The first question is whether the platform permits the account to be transferred at all. Some accounts are tied to an individual, business or organisation and may not be transferable through a private sale. Others may support an authorised change of administrator or ownership. The platform’s own process takes priority over any method offered by a seller. If a transfer is not allowed, changing credentials or copying browser data does not make it authorised.
The format should be part of the product description and match what was promised. A seller offering account credentials should not silently substitute a session file; an archive should not be described as a fully transferred account if it contains only a past browser state. Before accepting anything, clarify what access is included, which recovery channels remain attached, what the seller will remove, and what the buyer is expected to do next.
Login and password
With a login and password, the buyer receives the credentials used to sign in through the platform’s normal interface. The login may be an email address, username or another identifier. This is usually the easiest format to understand because the account can be tested through the platform’s own sign-in flow rather than through a copied browser session.
It depends on more than the password. Access may also rely on a mailbox, phone number, authenticator, recovery codes or approval from an existing administrator. If the seller still controls any of these, the buyer may be able to sign in but may not have durable control. A password that works once is not proof that the account has been fully handed over.
A first attempt can fail because the password is outdated, the login identifier is wrong, the account requires a verification step, or the platform flags a change in sign-in circumstances for review. The ordinary response is to use the platform’s stated recovery or verification process, not to seek a way around it. If the process requires a channel that the buyer cannot access, the account is not ready for independent use.
Where a transfer is allowed, the buyer should follow the platform’s supported ownership or administrator-change procedure. Then secure the account using its normal settings: establish control of approved recovery methods, review administrators and connected applications, and change credentials where permitted. The seller should remove their access through the same official controls. If the seller cannot or will not do so, treat the handover as incomplete.
Cookie export
A cookie export is a copy of browser data associated with a signed-in session. It is not the account’s password and does not, by itself, transfer ownership. In some circumstances, session data can grant access without a fresh password prompt, which makes it sensitive authentication material rather than a harmless convenience file.
Its usefulness depends on the platform, the browser, the session’s state and the way the platform validates access. A session may expire, be revoked, require renewed verification or fail when used in a different context. A cookie file can also be incomplete, stale or tied to a session that the seller has already ended. These dependencies make it fragile and difficult to assess from the file alone.
The first attempt may fail because the session is no longer valid or because the platform requests a normal sign-in and verification. There may also be no supported way to import that data into the buyer’s environment. The safe approach is not to treat a cookie as a substitute for the platform’s approved account-transfer process. Do not use copied session data to evade a login check, impersonate the seller or conceal who is accessing the account.
For the buyer, the key issue is control: a cookie rarely gives a clean way to manage recovery options, remove the seller’s access or prove ownership. If a seller offers only a cookie where credentials or an official administrator handover were promised, ask for the promised format or decline the handover. Avoid sharing or storing session files casually; anyone with valid session material may be able to access the account.
Access token
An access token is a credential issued to an application or service to authorise particular actions. Depending on the platform and integration, it may be limited in scope, linked to a particular app, or subject to expiry and revocation. It is not necessarily a way to sign in to the platform’s website, and it should not be assumed to represent full account access.
A token’s value depends on how it was issued, what permissions it grants, which application uses it and whether the platform still accepts it. The buyer may receive a string of characters but lack the application, configuration or authorised role required to use it. Even when it works, it may permit only a narrow task rather than account administration or recovery.
A first attempt can fail because the token is expired, revoked, miscopied, missing required permissions or associated with an application the buyer cannot access. The platform may also require the buyer to create their own authorised connection. Follow the platform’s documented developer or integration flow, and request permissions through the relevant account owner or administrator. Do not use a token to bypass consent, access controls or a normal verification step.
Afterwards, the buyer needs a legitimate way to manage the integration and the underlying account. That means confirming the permitted scope, identifying the application and its owner, removing access that is no longer needed, and using the platform’s supported controls to issue or revoke credentials. A token alone is not a complete account handover. If the seller promises general account control but supplies only an integration token, the delivery does not match the description.
Browser profile archive
A browser profile archive is a package of browser data, potentially including settings, extensions, saved site data and signed-in sessions. What it contains varies with the browser and the way the archive was prepared. It may preserve a familiar working environment, but it does not automatically transfer the account, its recovery channels or its legal ownership.
The archive depends on compatible software, intact files and the continuing validity of any included session data. It can also contain more private information than the buyer expects, such as unrelated browsing data or saved credentials. An archive that opens successfully may still fail to provide working access to a particular platform, and a working session does not establish that the buyer controls the account.
On the first attempt, the archive may be incomplete, incompatible, or unable to restore the original signed-in state. The platform may instead require the normal login and verification process. Do not use a profile archive to disguise the buyer’s identity, imitate the seller’s device or avoid platform checks. If the platform requires a fresh sign-in, use its ordinary process.
Before accepting an archive, agree on what it contains and what should be excluded. Treat it as sensitive personal data, scan and handle it cautiously, and do not retain unnecessary material. For lasting control, complete any permitted ownership or administrator change through the platform, secure recovery methods and remove the seller’s access. An archive is best understood as a working-environment package, not proof of a completed transfer.
Comparing control, durability and effort
In a simple comparison, login and password can offer the clearest route to ordinary sign-in, but control remains weak if recovery channels or administrator rights stay with the seller. A cookie may be quick to test but is usually fragile and provides little independent account management. A token can be durable for a defined integration when properly authorised, yet it may offer no general sign-in or ownership control. A profile archive may carry a broader browser environment, but its contents can be difficult to verify and its sessions may not last.
For effort, credentials are generally easiest to understand, although verification and recovery setup can take work. Cookies can appear simple but often leave the buyer dependent on a session that may stop working. Tokens require understanding the application and permissions involved. Archives require care in handling and may need compatible software, while still leaving account ownership unresolved. These are practical distinctions, not guarantees: platform design and the account’s status matter.
A useful way to judge any delivery is to ask three separate questions: Can the buyer reach the account through an approved route? Can the buyer manage its recovery and authorised users? Can the buyer continue using it without relying on the seller’s device, inbox, phone or application? A “yes” to sign-in alone is not enough.
What to put in writing before accepting
The seller’s description should name the exact format and explain its limits. It should say whether the handover is an official ownership or administrator change, direct credentials, an integration credential, or a browser-data package. It should also identify recovery methods that remain attached, any required verification, and which parts the seller will remove or retain. Avoid vague wording such as “full access” unless the parties define what that means.
The buyer should check the account through the platform’s normal interface and confirm that the promised functions are available. Do not assume that a screenshot, a file or a successful one-time sign-in proves continuing control. Keep a record of what was promised and what was delivered, without copying sensitive authentication material into informal notes or messages.
If the format does not match the agreement, pause rather than trying to make it work through unofficial methods. Request the agreed delivery or use the platform’s supported transfer route. If that route is unavailable, the account may not be a suitable product for the intended job.
Make the handover complete, not just usable
A workable account is one the buyer can access and manage within the platform’s terms. The delivery format is only one part of that outcome. The platform’s permitted transfer process, control of recovery channels, review of administrators and connected apps, and removal of the seller’s access all matter. A credential, token or archived profile cannot replace those steps.
Choose the format that matches the promised account and the intended, permitted use. Treat cookies, tokens and browser archives as sensitive material, not as shortcuts around normal sign-in. When a seller cannot provide a supported path to independent control, the safest conclusion is that the handover is incomplete—not that a more elaborate file will solve the problem.