Sharing a Browser Profile: File, Link, or Transfer?

The question before the mechanics

At some point you need to hand a browser environment to someone else - a teammate picking up a task, a client who bought an already-aged identity, a contractor who only needs it for a week. AntiBrow gives you three ways to do that: export it to a file, share it by link, or transfer ownership outright. They are not interchangeable, and the difference that matters is not what the recipient can do with it today - it's what happens on both ends after the handoff, and what you can and can't undo.

Export a file

Exporting writes the whole environment - its fingerprint, its cookies, its saved logins, its passkeys - into a single portable file. Hand that file to someone and they have their own standalone copy of what you had. From that point on, it is theirs: they can open it, edit its settings, re-export it, hand it to someone else. There is no link back to your account, no ongoing connection, nothing left for you to revoke.

That makes export the right choice exactly when you don't want an ongoing relationship. You're migrating a profile to your own second machine. You're closing out a contractor engagement and want a clean break instead of a standing grant of access. You're selling an aged account somewhere that doesn't integrate with AntiBrow's own transfer flow, and a file is the only thing the buyer can accept. In every one of these cases, the fact that you can't take it back afterward isn't a downside to work around - it's the entire point. A file is a copy, and a copy that can be revoked isn't actually a copy.

The cost is exactly the flip side of that: the moment you hand over the file, you've lost your only lever. If you change your mind ten minutes later, there is nothing to click.

Share a link

A share link is the opposite trade. The recipient doesn't get a file - they sign in to their own AntiBrow account (a free one is enough) and the environment shows up in their client, ready to open. They can look at its fingerprint and browse with it. They cannot rename it, change its settings, delete it, export it to a file, or share it onward to someone else. Those actions never leave the owner's hands.

Two details make this meaningfully different from handing someone a copy. First, if the environment runs on your managed proxy, the recipient browses through it without ever being shown its host, username or password - the credentials stay server-side no matter how many times they open the environment. That only holds for a managed proxy, though: if the environment instead runs on a proxy you added yourself, that proxy isn't part of the share at all, and the recipient will need one of their own before they can open it. Second, and less obvious: a share is one archive, not two copies drifting apart. The owner and the recipient are working against the same saved state. A cookie or a login your teammate writes during their session is what you see the next time you open the environment yourself, and the reverse is equally true. If two of you use it in quick succession expecting to each keep your own version of events, you won't - that's a single shared browsing history, not a snapshot handed over once.

You can revoke a share at any point, which is the capability export doesn't have. But revoking is a narrower tool than it sounds, and it's worth being precise about what it actually does, because the imprecise version is the kind of promise that gets a product in trouble.

Revoking removes the recipient's path back in - it does not reach onto their computer. It takes the environment out of their client and stops it from being opened again. If a managed proxy was attached, revoking also cuts off the credential they were browsing through, so they lose that exit IP along with the environment. What it does not do is touch anything already written to their disk. Any cookies, logins or local storage that landed there while they had access are still there after you revoke - there's no copy on their machine you can reach out and erase. And a proxy connection that was already open at the moment you revoke isn't guaranteed to end the moment you click the button; new connections stop being accepted, but an existing one can keep running for a while before it's actually cut. Treat revocation as "they can't come back in," not as a hard stop to whatever they were doing at that exact moment.

Transfer ownership

Transfer is the option that looks the most like a sale, because functionally it is one. Like a share, it's generated as a link from the same menu - but accepting it doesn't add the environment alongside the recipient's own; it moves ownership there and takes it out of your account.

It comes with a prerequisite a share link doesn't have - though not the hard wall it used to be. A paying recipient needs room in their profile quota, and in their proxy quota too if the environment is bound to a managed proxy, because the proxy moves with the environment and now counts against their limit instead of yours. A recipient with no paid plan can accept as well, by way of a one-time 30-day handover window instead of quota. If the environment instead runs on a proxy you added yourself, its credentials are copied to the recipient as part of the transfer - this is the one place export, share and transfer disagree with each other, because export and transfer both hand the credentials over while a share link never does.

There is no revoke on a transfer. Once the recipient accepts, the environment is out of your account, full stop. The only way back is the new owner deciding to share or transfer it back to you - which is a choice on their side, not a button on yours.

Choosing

If you want a clean, permanent handoff with no ongoing account relationship on either side, export a file. If you want someone to use an environment while you keep the ability to end that access later, share a link - and go in understanding that "later" means blocking new access, not reaching back to erase what they already have. If you're selling or permanently reassigning an environment inside AntiBrow itself, transfer it - checking first that a paying recipient has the quota headroom, or that a recipient with no plan still has their one-time handover window to spend.

The three options aren't ranked by how much they do for you. They're ranked by how much you're willing to give up, and for how long.

Further reading

The sharing & transfer overview has the full comparison side by side. The sharing docs cover the exact mechanics - API endpoints, expiry windows, and what a recipient sees in the desktop app.