VirtualBrowser: a free Chromium fingerprint browser for Windows

What VirtualBrowser actually isolates, and for whom

VirtualBrowser targets a narrow problem: one physical Windows machine needs to present several browser identities that do not look related to each other. The README frames this around browser fingerprints, which it defines as signatures built from User-Agent, language, resolution, fonts and Canvas or WebGL noise. The project's stated goal is to isolate those signals per environment so that accounts are harder to link.

The intended user is someone running many accounts or scraping sessions from one box: affiliate marketers, e-commerce sellers with multiple storefronts, web3 airdrop participants (the repository description names this case directly), and engineers who need repeatable browser identities for automation. It is not a privacy browser for casual reading. There is no claim of anonymity against a network observer, only of separating environments from each other. The disclaimer is explicit that the project is for technical exchange, learning and research, and that the authors accept no liability for misuse.

How the fingerprint isolation is wired

The mechanism is a patched Chromium build plus a management shell. The repository layout shows a server directory and a worker directory alongside the Vue front end, and the README describes a single application that creates, starts, edits and deletes browser environments from one list. Each environment carries its own configuration, and launching it opens a separate window that the README calls an independent fingerprint instance.

The fingerprint surface is broad and mostly API-level. According to the README table, VirtualBrowser can modify the operating system and browser version fields inside navigator.userAgent, set navigator.language and navigator.languages, adjust the Date time zone, configure WebRTC leak protection, override navigator.geolocation, set screen.width and screen.height, randomize the available font list, inject 2D and WebGL drawing noise, change WebGL vendor and renderer metadata, add noise to AudioContext getChannelData and getFloatFrequencyData, and touch hardwareConcurrency plus device name and MAC identifiers. Several of these, including language, time zone and geolocation, can be matched automatically to the proxy IP.

The proxy setting offers three modes: default, no proxy, and custom. That is the whole documented proxy story. There is no mention of proxy pools, rotation, health checks or per-profile credential storage beyond the custom option. For a tool sold on multi-account work, that is the weakest part of the design, and anyone with more than a handful of profiles will end up managing proxies outside the app.

Installing VirtualBrowser and creating a first profile

VirtualBrowser ships as a Windows installer, not as a package on a registry. The README points to the GitHub Releases page and to the official sites virtualbrowser.cc and vbbrowser.com, and states that it supports Windows 7 and above. There is no npm, pip or Docker path documented, so the install is a download and a normal setup wizard.

After installation, the workflow is three steps. Open the application and click the create-browser button:

打开 VirtualBrowser，点击「创建浏览器」

A dialog appears where you can change the configuration or accept the defaults. The README shows the default path as acceptable, so a first profile can be created without touching any fingerprint field.

Once the profile exists, start it from the environment list:

在环境列表中点击「启动」

The README states that the newly opened window is that environment's independent fingerprint instance. To check what the site actually sees, the README recommends loading FingerprintJS or BrowserLeaks inside that window. Compare the reported User-Agent, time zone and Canvas hash against a second profile you create with different settings; if both profiles return identical Canvas or WebGL values, the noise settings are not taking effect and you should adjust them before doing any account work.

For automation, the README says the Chromium base is compatible with Playwright and other Chromium automation tools, and points to the automation directory in the repository for example code. It does not document a remote debugging port or a specific launch flag, so read that directory before assuming a connection method.

Where VirtualBrowser falls short

The most concrete limitation is platform coverage. The README states that Mac, Android and Linux are planned, which means today the product is Windows-only. If your fleet is mixed, this is a single-OS tool and nothing in the documentation suggests a server or headless deployment path.

The second gap is verification. The README tells you to test with FingerprintJS and BrowserLeaks but publishes no results of its own. There is no table of which detectors pass, no list of known-failing sites, and no compatibility matrix. The contribution section asks users to report sites that do not work, which confirms that breakage is expected and unsystematic. You are the test suite.

Third, the repository contains a server and a worker directory but the README does not describe what they do, whether the management UI talks to a local service, or whether profiles are stored in a database. That matters for backup and for anyone who wants to move profiles between machines. Profile export and import are not documented at all.

The licence is BSD-3-Clause, which permits commercial use and modification, but the disclaimer limits the project to technical exchange and research and disclaims accuracy and fitness. Those two statements sit awkwardly together, and if you plan commercial deployment you should read the LICENSE file and the disclaimer yourself rather than treating this as legal advice.

VirtualBrowser versus the usual alternatives

The closest comparison is a commercial anti-detect browser such as GoLogin, Multilogin or AdsPower. The difference is not the fingerprint list, which is broadly similar across that category, but the operating model: those products typically run a cloud profile store and a team-sharing layer, while VirtualBrowser is a local Windows application with a single-machine environment list. If you need several operators sharing profiles, the README describes nothing for that.

A second alternative is plain Playwright with a fresh browser context per account. That is free, scriptable and cross-platform, but it does not touch Canvas, WebGL, AudioContext or font enumeration, so contexts remain linkable through those signals. VirtualBrowser exists precisely to close that gap, and its Playwright compatibility means you can keep the automation layer and swap in the fingerprinting underneath.

A third option is a disposable cloud or sandbox browser. Those isolate the whole machine rather than the fingerprint, which is stronger separation but a different cost model and no persistent identity per account. If your problem is account linkage rather than machine compromise, VirtualBrowser's approach is the more direct one.

Release cadence, upgrade cost and licence terms

The last push to the default branch was on 2026-07-30, and the most recent tagged release is 2.3.1 from the same day, following 2.3.0 on 2026-07-29 and 2.2.16 on 2026-05-13. The repository is not archived. The release history shows a burst of activity in late July after a quieter May, so the cadence is uneven rather than steady.

Upgrade cost is hard to estimate from the documentation. Because the README does not describe where profiles are stored, it does not say whether an installer upgrade preserves existing environments or whether fingerprint settings survive a version bump. Anyone running production accounts should test an upgrade on a spare machine first and confirm that profiles still launch with the same values.

The licence is BSD-3-Clause, which allows redistribution and commercial use provided the copyright notice and licence text are retained. The README's disclaimer separately restricts use to technical exchange, learning and research and disclaims any warranty of accuracy or fitness. Those are different instruments and they do not obviously agree. Read LICENSE and the disclaimer in full before shipping anything built on this.

Editorial conclusion

Adopt VirtualBrowser if you need several isolated Chromium profiles on one Windows 7 or newer machine and you are willing to verify each profile yourself against FingerprintJS or BrowserLeaks, because the README publishes no test results of its own. Do not adopt it if you need macOS, Linux or Android today, since the README states those platforms are only planned, or if you need documented proxy rotation, profile export or rollback, none of which the README describes. Before relying on it, install a release, create one profile, point it at a proxy, and check the resulting fingerprint on BrowserLeaks.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. Virtual-Browser/VirtualBrowser on GitHub