# BotBrowser: a Chromium core that tries to look the same everywhere > A TypeScript-labelled MIT repository holding a patched Chromium build whose whole purpose is keeping fingerprint signals uniform across operating systems, plus the tooling to launch it, automate it and check whether it still passes the tracking detectors. The code is free and the profile packages are not. **botswin/BotBrowser** — Advanced Privacy Browser Core with Unified Fingerprint Defense: Cloudflare, Akamai, Kasada, Shape, DataDome, PerimeterX, hCaptcha, FunCaptcha, Imperva, reCAPTCHA, ThreatMetrix, Adscore - Repository: https://github.com/botswin/BotBrowser - Website: https://botbrowser.io - Stars: 2,635 · Forks: 280 - Language: TypeScript - License: MIT - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/botswin-botbrowser ## What the project is, and the framing it picked BotBrowser is a privacy-first browser core built for one specific property: the same fingerprint on every machine you run it on. The README states the goal plainly, that it keeps fingerprint signals uniform across every platform so tracking systems cannot collect and correlate data to identify a user, and that running the same profile on Windows, macOS or Linux produces an identical fingerprint posture each time. That framing matters because it is narrower than the vendor list in the repository description would suggest. That description names Cloudflare, Akamai, Kasada, Shape, DataDome, PerimeterX, hCaptcha, FunCaptcha, Imperva, reCAPTCHA, ThreatMetrix and Adscore, which reads like an evasion product. The README itself talks about tracking defence instead, citing W3C, browser vendors, privacy regulators and academic research as recognising browser fingerprinting as a privacy threat, and pointing at `FINGERPRINT_PRIVACY.md` for the references. Topics on the repository match that reading too: `anti-detection`, `bot-detection`, `privacy` and `webdriver` sit alongside `chromedriver` and `scraping`. The project is unusually explicit about how it wants to be used. Engineering is described as focused on privacy research, cross-platform tracking-resistance validation and maintaining protected environments for authorized defensive benchmarking, and the README asks reviewers to read `DISCLAIMER.md` and `RESPONSIBLE_USE.md` first. Those two files being in the root, rather than buried, is a reasonable signal about intent. One structural detail worth understanding before reading further: the browser is a patched Chromium, not a JavaScript library. The repository language is TypeScript, but the substance lives in `patches/`, and everything else is the distribution machinery around a binary. Understanding that saves you from grepping the tree for a JavaScript entry point that does not exist. ## Cross-platform parity, and the tier system behind it The central engineering claim is that a single profile produces the same user agent, screen metrics, touch surfaces, fonts and device APIs no matter which host is running it. The README breaks the coverage into tiers, which is the most useful thing in it: - Windows, macOS and Linux sit at enterprise Tier1. - Android WebView is a PRO feature. - A Trimmed Build at ENT Tier3 targets Linux x64. - WebKit-family profile bundles are ENT Tier4. The reason a tier system exists at all is maintenance. A fingerprint that is right for one platform goes stale as soon as that platform's browser changes, and a stale fingerprint is a fingerprint that correlates. The README says the core is built on the latest stable Chromium for exactly this reason, to keep fingerprints aligned with current browser behaviour and reduce stale-engine correlation risk. Every release tag in the recent list confirms the practice: 154.0.8037.44 and 153.0.8010.50 both published on 2026-09-21, and 154.0.8037.17 three days earlier, each one a Chromium core bump to the matching Chrome stable release. Configuration is mostly automatic. Locale, timezone and language derive from the proxy IP, with touch simulation and device metrics handled in the built-in configuration, and CLI overrides available when a specific privacy experiment needs them. `WEBKIT_PROFILE_CONSISTENCY.md` covers the WebKit side, and `docs/guides/platform/ANDROID_WEBVIEW.md` covers the WebView profile. The README also links demo recordings against CreepJS, Iphey and Pixelscan on Android, which tells you the intended acceptance test: not a lab instrument, but the same public detection pages anyone can load. ## Launching it, and the fact that profiles are gated Launching from the command line takes a profile file and a user data directory, and the README is emphatic that paths must be absolute: ```cmd chrome.exe --bot-profile="C:\absolute\path\to\profile.enc" --user-data-dir="%TEMP%\botprofile_%RANDOM%" ``` Two details carry weight. The profile is an encrypted `.enc` file, so it is an artifact handed to you rather than a directory of state you create. And the user data directory is parameterised with `%RANDOM%`, which is the trick for running several instances side by side without them fighting over the same Chromium data directory. The macOS and Linux commands follow the same shape. There is a GUI path as well: `BotBrowserLauncher` in `launcher/` handles profile selection and multi-instance management, which is the reasonable choice if you are evaluating rather than integrating. `INSTALLATION.md` carries the full instructions per platform. The gating is the part that surprises people. BotBrowser 150 and newer profiles are available through subscription or through support at the address on the site, or the Telegram support channel, while legacy demo profiles remain available for earlier evaluation lines. So the browser binary is free and the MIT-licensed repository contains the whole build, but the profile that gives it its defining property ships separately. `profiles/` exists in the tree, and the commercial relationship to it is worth understanding before you build a pipeline around it. ## Automation, and what changes when you spawn contexts The automation story is the reason to look past the privacy framing. The repository ships `examples/playwright/`, `examples/puppeteer/`, `examples/bot-script/`, `examples/mirror/` and `examples/storage-access/`, and the README's minimal Playwright example is the familiar shape with two changes: `executablePath` points at the BotBrowser binary, and `--bot-profile` is passed as a launch argument. `botbrowser-control/` exists as a separate control surface. The README highlights CDP leak blocking, which is the detail to sit with. When you attach a browser automation protocol client, the instrumentation itself can become a signal, so a tooling layer that announces itself defeats the browser it is driving. The most interesting feature is per-context fingerprinting, documented separately in `PER_CONTEXT_FINGERMENT.md`. Independent fingerprint bundles per `BrowserContext`, without spawning new processes, with millisecond-level switching and reduced memory overhead. For a workload that needs many distinct identities, that is the difference between one process and hundreds. The reported figures are 29% memory savings at scale, and a Trimmed Build at ENT Tier3 claiming 62% lower wall time and 85% faster per-context spin-up on Linux x64. `ADVANCED_FEATURES.md` carries the capabilities index and the network fingerprinting section, including full-proxy QUIC and STUN over SOCKS5 so geo metadata does not leak through the transport. There is also `tools/mirror/`, which synchronises input across multiple instances at once. That exists to validate that several browsers agree on their posture, which is exactly the failure mode per-context fingerprints introduce. ## Verification and the performance claims Two documents carry the evidence a sceptical reader wants. `VALIDATION.md` handles verification, and `BENCHMARK.md` handles performance. The performance claims are specific enough to be useful: Speedometer 3.0 within 1% of stock Chrome, zero fingerprint API overhead across macOS, Linux and Windows, the 29% memory figure above, and the Trimmed Build numbers. `BENCHMARK.md#trimmed-build` has its own section. `FINGERPRINT_PRIVACY.md` is the privacy argument, and `TRIMMED_BUILD.md` covers the reduced build separately from `BENCHMARK.md`. `CLI_FLAGS.md` has a flag directory with anchors, which is the reference to bookmark once you are past the first launch. For your own checks, the README points at CreepJS as the confirmation step after launch, with Iphey and Pixelscan as the alternatives, and `examples/mirror/` as the way to check several instances agree. The honest framing here is that no fingerprint can be verified as undetectable by the project itself, only as consistent by whatever detectors you choose to run. BotBrowser gives you the uniformity and the tooling to test it; whether that is sufficient depends on the systems on the other end. There is also an `llms.txt` at the repository root, which is a small sign of how the project expects to be consumed by tooling rather than only by browsers. ## Project shape, cadence and licensing The repository has 2614 stars, 278 forks and 3 open issues, is not archived, uses `main` as its default branch, and was last pushed on 2026-09-24. The licence field reads MIT and there is a `LICENSE` at the root. An open issue count of 3 on a project with this many stars usually means support is handled off-repository, which fits a product with a subscription component. The release cadence is the clearest signal about the maintenance model. Three of the most recent releases are Chromium core bumps rather than feature announcements, and two of them shipped on the same day minutes apart: 154.0.8037.44 at 02:12 and 153.0.8010.50 at 02:12:11 on 2026-09-21. That is what tracking Chrome stable looks like, and `CHANGELOG.md` is linked from each release body for anything beyond the core version. Practically it means you should pin a version and expect your pinned version to fall behind Chrome within weeks. The tree also has `docker/`, `tests/`, `scripts/`, `docs/` and `bench` adjacent material such as `BENCHMARK.md`, so there is a build and test story rather than a single opaque binary. But the honest summary of the split is this: MIT covers the patched Chromium build, the tooling and the documentation. The profile packages for BotBrowser 150 and newer, the subscription route to them, and the enterprise tiers are a separate commercial arrangement. For anything beyond evaluation, that distinction is the first thing to establish in writing. ## Conclusion BotBrowser is worth an afternoon if your problem is profile consistency rather than raw evasion: one encrypted profile that reports the same screen, fonts, touch surface and device APIs whether it launches on macOS, Windows or Linux. Download the release for your OS, launch it with an absolute profile path, then check CreepJS before anything else, because a browser whose posture differs between machines defeats its own purpose silently. Two practical cautions. First, the Chromium core moves fast: releases 154.0.8037.44 and 154.0.8037.17 both landed on 2026-09-21, seven minutes apart, so pin a version rather than tracking latest. Second, the repository is MIT but the profile packages for BotBrowser 150 and newer come through subscription or support, so read the licensing and the responsible-use guidelines before you decide how this fits your work. ## FAQ ### Is BotBrowser free to use? The repository is MIT licensed and the Chromium build, tooling and documentation are open. The profile packages are a separate matter: BotBrowser 150 and newer profiles are available through a subscription or through the project support channels, while legacy demo profiles remain available for earlier evaluation lines. Enterprise tiers for WebView, Trimmed Build and WebKit bundles are likewise gated. ### How do I launch BotBrowser with a profile? Pass the encrypted profile file and a user data directory to the binary, and use absolute paths for both. The README's Windows form is `chrome.exe --bot-profile="...profile.enc" --user-data-dir="%TEMP%\botprofile_%RANDOM%"`, and macOS and Linux follow the same pattern. Parameterising the user data directory is what lets several instances run at once without colliding. ### What is per-context fingerprinting in BotBrowser? It gives each BrowserContext its own independent fingerprint bundle without spawning a new process. The documented effects are millisecond-level switching between contexts and lower memory overhead, with the README reporting 29% memory savings at scale and a separate Trimmed Build figure of 85% faster per-context spin-up on Linux x64. ### How do I check whether a BotBrowser profile still passes fingerprint detection? The README's verification step is to load CreepJS, with Iphey and Pixelscan as alternatives, right after launch, and to confirm the posture is the same as on your other machines. `VALIDATION.md` covers verification in detail and `tools/mirror/` synchronises input across several instances so you can confirm they agree with each other. ## Sources - [botswin/BotBrowser on GitHub](https://github.com/botswin/BotBrowser) - [License: MIT](https://github.com/botswin/BotBrowser/blob/main/LICENSE) - [Project website](https://botbrowser.io) - [README](https://github.com/botswin/BotBrowser/blob/main/README.md) - [Releases](https://github.com/botswin/BotBrowser/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/botswin-botbrowser