Antidetect browser profile sharing
Antidetect browser profile sharing gives another account or team a copy of selected browser profiles. In WGBrowser, you can use a share code or export a file and choose whether to include sign-in data, a proxy, and account credentials. Once received, each copy stores its own subsequent changes.
For your own computers, use cloud sync to continue with the original profile. Within one team, adjust member access to hand over the same profile. A share code or .fgbx file is useful when the recipient needs a separate copy, including someone using the Lite edition without an account.
Choose what the recipient gets
Profile names, notes, tags, appearance, fingerprint settings, platform URLs and usernames, startup URLs, sync options, and launch options are copied with the profile. The saved fingerprint configuration and seed stay the same. Claiming several copies does not generate several different fingerprints.
The optional content controls are Cookies and local storage, Proxy, Passwords and 2FA, and Saved site passwords. Cookies and storage carry session data; platform credentials support signing in again; saved site passwords come from that profile's password manager. Select the items the recipient needs for the work you are handing over.
A fixed proxy selected from the source team's library becomes a custom proxy in the copy, including connection credentials. Extensions are matched by extension ID against those already available in the recipient's team. Missing extensions are not installed automatically, so have the recipient check any extension required by the workflow.
Create and claim a share code
Creating a share requires a plan with profile sharing and permission to export profiles. Each source profile must be visible to you and outside the trash. Unavailable content choices show the applicable permission or plan restriction. Check plans and pricing before preparing a handoff that depends on these options.
The recipient can paste the code or the entire message containing it into Claim share. The preview shows the sender, expiry, remaining claims, profiles, and included data. Review the preview before submitting, particularly if the sender selected several profiles or you already have profiles with the same names.
- In Profiles, select the profiles and choose Share. Set the contents, Valid for, Can be claimed, and Note, then choose Create code.
- The recipient opens Profiles → Claim share, previews the contents, selects profiles, and sets Add to group and Duplicate names.
- Check Copy local storage too and any capacity messages. Claim the selected profiles, review the result, and open the relevant sites to verify the accounts and sessions.
Which source state is copied
A share code copies the source's current state when it is claimed. It does not freeze a backup when you create the code. Cookies follow their sync process, while storage comes from the latest uploaded snapshot after the source profile closes. Finish the website work, close normally, and wait for sync before the recipient claims it.
The received profile is independent. Later changes to the source name, proxy, or website session do not keep updating an already claimed copy. If colleagues need to alternate on the same profile, use team management and the original profile's access rules.
In the full edition, claiming requires Create profiles permission and enough capacity under both the team's plan and the member's creation limit. Storage copying also requires the storage sync feature and available cloud storage. Without storage sync, only cookies are copied from the selected session data; inspect the preview before treating the handoff as a storage restore.
Export and import a .fgbx file
For a file handoff or saved backup, select Export and choose Full backup. A .fgbx file can include the fingerprint, cookies, local storage snapshot, platform credentials and 2FA secret, and saved site passwords. Encryption is selected by default when sign-in data or passwords are included. Review the content switches and encryption choice before saving.
Close the source and finish syncing before export. Read the result: a failed storage download can leave a file with cookies only, and permission or plan limits can omit selected items. Resolve those messages before sending a file that the recipient expects to contain storage. Later source changes do not update the exported file.
When importing an encrypted backup, enter its password, then inspect the row preview, default group, duplicate-name handling, storage restore choice, and remaining profile capacity. File imports currently do not restore the last open tabs; reopen the necessary pages afterward.
JSON stores full configuration without local storage. CSV stores common fields without a complete fingerprint. For moving cookies on their own, use the cookie import and export guide and check the session on the destination website.
Share profiles with a Lite user
When the recipient has no client account, select Allow Lite claims while creating the share code. This option is off by default. The recipient previews and claims the profiles in Lite; the downloaded profiles and later browsing data stay on that computer.
A file handoff to Lite requires a .fgbx file with valid profile credentials. Not every full backup contains those credentials, so check the export result for Lite compatibility. First use requires an online source check; the profile's proxy and websites still have their own connection requirements.
Lite does not provide cloud sync, team collaboration, or continuing updates from the sender. Recipients who need to create profiles, edit fingerprints, or use automation should use the full edition. Review the Lite edition before choosing the receiving client.
Review claims and revoke unused codes
Open Share history to inspect code status and claims or choose Revoke share. Owners and admins can review all team shares; regular members see their own. Revoking a code prevents later claims. It does not delete a copy already received by another team or a Lite device.
After receipt, verify the account shown by the website, the proxy exit IP, required storage, and any 2FA details included. A data transfer does not guarantee that a website session remains valid. Complete any verification requested by the website before continuing the work.
Record which profiles were received and whether their required data is present. Revoke a still-usable code when you no longer need further claims. The recipient manages copies already created; for a change of responsibility inside the same team, review group access before creating extra copies.
FAQ
Do shared browser profiles keep syncing with the sender?
No. Claiming a share creates an independent profile in the receiving team or on the Lite device. Later changes are saved separately. When colleagues need to take turns using the same profile, keep it within one team, assign the relevant access, and close it on the current device before the next person opens it.
Can I revoke a browser profile after someone claims it?
Revoking the share code stops additional claims. It does not recall or delete profiles already copied to another team or Lite device. Check the recipient and included data before creating the code. Once claimed, that independent copy is managed by the recipient, while website access still depends on the site's session state.
Does a share code use the data from when it was created?
The claim uses the source profile's current state at claim time. Cookies follow their sync updates, and storage comes from the latest uploaded snapshot after a normal close. Finish your work, close the source profile, and wait for sync before the recipient claims it. Use a file export when you need a saved backup.
Can someone receive a browser profile without an account?
Yes, through the Lite edition. Enable Allow Lite claims when creating a share code, or provide a .fgbx file with valid profile credentials. The recipient stores the received profile locally. Lite has no cloud sync or team collaboration, and the sender cannot recall a profile that the recipient has already claimed.