BitBrowser alternative for antidetect browser migration

WGBrowser is a BitBrowser alternative that imports supported profile JSON and offers common compatible Local API paths on BitBrowser's default port, 54345. You still need new profile IDs, an API key and checks for unsupported behavior.

Use one profile to verify the import and a complete automation run before moving a larger account set. This guide covers accepted file structures, field conversion, connection details and the differences that matter when you adapt an existing workflow.

Updated 2026-11-01

Prepare the BitBrowser profile JSON

Supported sources include BitBrowser /browser/detail responses, /browser/list responses, individual profile objects and arrays of profile objects. The importer converts recognized fingerprint, proxy and account fields into new profile configurations. It reads cookies from cookie and uses groupName as the group name.

Record the relationship between each profile, platform account and proxy before exporting. A list response and a detail response may contain different information. Inspect the actual records: data absent from the source cannot be recovered by the import process. If continuing a login session matters, verify that cookies are included instead of relying on a filename or profile count.

The application's own .fgbx backups, full configuration JSON and general spreadsheets use other import routes. If your source is a table, review the general migration guide. The cloud sync guide explains how configuration files and stored login data differ.

Review the import preview

Open Profiles → Import, choose the JSON file and confirm that the preview recognizes the BitBrowser format. Check names, groups, proxy connections and cookie counts. Resolve malformed rows before submitting, then compare the result with the number of profiles you intended to move.

Supported fingerprint fields are converted, including settings for device templates, language, time zone, WebRTC, location and noise. Unsupported fields are ignored, with relevant parameters generated from a template. The resulting profile therefore needs inspection; importing does not reproduce every underlying fingerprint value from the source browser.

Choose a Default group for rows without a group. Keep a recognizable source name so you can compare the imported profile with the original.
Under Duplicate names, choose Rename (add a number), Skip duplicates or Keep the name. Check the remaining profile allowance before importing.
Review created, skipped and failed records. Profiles beyond the available allowance are not created; prepare any retry from the unfinished records to avoid duplicate imports.

Connect through the compatible Local API paths

Open Settings → Local API and enable the Turn on Local API setting. The default port is 54345, matching BitBrowser. If another service already uses it, choose an available port and update the script's base address. Send JSON requests with the new key in x-api-key or the Authorization: Bearer header.

Common open and close paths include /browser/open, /browser/close, /browser/close/byseqs and /browser/close/all. Query paths include /browser/list, /browser/detail, /browser/pids, /browser/pids/all, /browser/pids/alive and /browser/ports. Start with list and detail requests so you can confirm the target profile before running page actions.

Create and update paths include /browser/add, /browser/modify, /browser/update and /browser/update/partial, plus /browser/proxy/update, /browser/remark/update and /browser/group/update. Cookie operations use /browser/cookies/get, /browser/cookies/set and /browser/cookies/clear. Check request fields and connection examples in the Local API guide before adapting a production script.

Update identifiers and CDP connections

Imported profiles receive their own IDs and profile numbers. Replace the old identifiers in your scripts, along with the API key and any changed service address. An unchanged profile name does not make the old software's ID valid in the new application. Confirm the name and account returned by a detail request before opening it.

The ws and http values returned by /browser/open point to a local CDP gateway for Puppeteer or Playwright. The gateway exposes website tabs; the profile window's address bar and tab bar do not appear as automation pages. The debugging port may change when a profile reopens, so use the address returned by the current request.

Test the complete sequence of opening a profile, finding the expected page, reading or entering data and closing normally. If your team will run the same task as a plugin instead, review browser automation and test that implementation separately. Importing a profile does not migrate an automation task's logic.

Check unsupported behavior and response fields

Headless mode is not supported. Other extra launch arguments are ignored, and a profile cannot create another isolated browser context inside itself. Each profile is already an independent browser. A script that relies on headless launches or nested contexts needs a revised execution model before you can evaluate its result.

The open response returns driver as null; connect through CDP instead of expecting a bundled ChromeDriver path. /browser/list omits password fields, so use /browser/detail when the permitted task requires profile details. The endpoint families browserTag/* and rpa/*, plus autopaste and alldisplays, are not provided.

A business operation can return HTTP 200 with success: false. Check the response's business result instead of treating the status code alone as success. Also handle profiles occupied by another device. Compatibility covers the documented paths and fields; review every endpoint your script actually calls.

Verify the account workflow after migration

Open a small sample and compare the account, startup URLs and group with your source records. Check the actual website login state, then verify the proxy exit IP and region. A saved proxy address does not prove that the connection is still available. Follow the proxy setup guide when checking connection failures or location mismatches.

Review the device template, language, time zone, location and noise settings. Restart a profile after changing settings that apply on launch. Once the manual workflow is verified, run the adapted script from start to finish and check the closing and synchronization result before extending it to more accounts.

FAQ

Can I reuse my BitBrowser scripts?

Scripts using the documented compatible paths can keep their general request structure, but need the new key and profile IDs. Check the service port, response fields and launch options as well. Verify one complete run, including opening the profile, connecting to its current CDP address, working with the page and closing it.

Does BitBrowser JSON import preserve login sessions?

The importer reads cookies present in the source JSON. It cannot fill in missing login data or determine that a website will still accept an old session. Check the cookie count in the import preview, then open the target site. Complete its sign-in or verification process if required.

What if BitBrowser is already using port 54345?

Two services on the same computer cannot listen on the same address and port at once. Turn off the Local API you are not using, or choose another port in WGBrowser under Settings → Local API. Update your script's base address to match, then test a request with the new key.

Will the imported fingerprint exactly match BitBrowser?

Do not assume every underlying value will match. Supported BitBrowser fingerprint fields are converted, while other parameters are generated from a device template. Review the template, language, time zone, location, noise settings and proxy exit IP after import, then verify the website and automation workflow you intend to use.