WebLibre: a Gecko browser built around containers and local search

A Gecko browser that is not a Firefox fork

WebLibre renders with the same engine as Firefox, which is the part that matters for compatibility. Websites and extensions behave the same because the browser is built on Mozilla's Gecko engine and Mozilla Android Components. Extensions that work in Firefox on Android are the same extensions you install here.

What differs is the shell. The project states plainly that WebLibre is not a Firefox fork and is its own browser experience, aimed at people who want everyday browsing while keeping control over how sites, identities and network connections are separated. The extra layers it adds on top of Gecko are concrete rather than cosmetic: isolated tabs, containers with per-container cookie isolation, Tor and proxy routing, a built-in multi-protocol proxy client, tree-style tab management, and on-device local search across tabs, history and feeds.

The code is Dart, and the repository is laid out as a Flutter-style monorepo with an apps directory, a packages directory, native code and a scripts directory. There is also a Gemfile at the root, which points to a Ruby tooling layer alongside the Dart code, and translation status is tracked through a Weblate instance.

The project labels itself Early Access and warns that features and settings can change, that some updates may cause problems, and that many people already use it daily. Treat that warning as part of the specification rather than a footnote.

Cookie isolation is a per-container switch, not a global promise

Containers are the core of the privacy model, and the interesting detail is that cookie isolation is opt-in per container. Enable Cookie Isolation on a container and it gets its own cookies, logins and site data, separate from every other container. From there you can add clear-on-exit rules and point that container at Tor or a proxy.

Sites can be assigned to containers automatically, so the separation does not depend on you remembering which container to open. The practical effect is that a shopping account, a work account and a personal account can live in the same browser without sharing cookies, and each can travel through a different network path.

A second, less visible mechanism sits alongside this. There is an Intent Gatekeeper for links opened by other apps, which matters on Android because any other application can ask a browser to open a URL. The browser also strips tracking information from URLs, sends Global Privacy Control, and offers screenshot protection as an option.

All of this is adjustable. The documented trade-off is blunt: stronger protection can break some websites, so a site exception or a less strict mode exists for those cases. That is a real cost of the defaults, and you will hit it on a site that depends on third-party cookies.

Isolated tabs outlive a restart, private tabs do not

WebLibre offers three kinds of tab, and the difference between them is about persistence rather than about masking.

Regular tabs are the normal case. Private tabs behave the way users expect private mode to behave. Isolated tabs give each one a separate session from every other tab, and the crucial part is that they remain open after you quit and reopen the browser. An isolated tab is therefore closer to a named session than to a temporary window, which makes it the natural home for a long-running task such as a multi-step sign-in flow.

Around the tabs sits the management layer. Tabs can be arranged in list, grid or tree views, with parent and child relationships, stacking, filtering, pinning, bulk actions and a quick switcher. A tree view matters more than it sounds, because the tree reflects the relationship between tabs rather than just their order, and it is the main answer to the problem of a hundred flat tabs on a phone.

The third tab type and the container system overlap in what they isolate. The tab isolates a session per tab, the container isolates a set of sites and can carry a network route, and the documentation describes both as ways to keep activities apart.

Getting the APK and checking the signature before you install it

WebLibre requires Android 8.0 or newer, and the project recommends Android 13 or newer, warning that on Android 12 and older you may see visual problems. There is no command line installation path in the documentation, so the install is done by downloading or installing the app from one of three channels.

GitHub Releases offers direct downloads, and Obtainium can manage updates from those releases. Most current devices want the arm64-v8a APK, armeabi-v7a is for older 32-bit devices, and x86_64 covers emulators, ChromeOS and x86 tablets. Google Play provides automatic updates. F-Droid publishes its own builds and signs them with its own key, which means new versions can arrive considerably later than on GitHub or Play because of the build process and manual review.

If you downloaded an APK, the project documents how to confirm it is an official build, and the certificate fingerprints for the two signing paths are published separately:

apksigner verify --print-certs

Run that against the downloaded file and compare the printed SHA-256 certificate fingerprint with the one published for your channel. The GitHub and Play builds share one fingerprint, and the F-Droid build has its own.

F-Droid and GitHub builds cannot be swapped without losing data

This is the sharpest operational edge in the project, and it will catch anyone who moves between distribution channels.

An F-Droid build and a GitHub or Google Play build are signed with different keys, so you cannot switch directly between them. You must uninstall the current build first, and uninstalling deletes your data.

The way out is documented. Before uninstalling, create an encrypted profile backup. Use Change Backup Directory to save that backup outside WebLibre's own app storage, and then verify the backup. The point of moving it outside app storage is that the backup survives the uninstall that deletes the app data, and the point of verifying it is that a backup you never checked is not yet a backup.

The project also offers a Restore from Backup path on first launch, which imports an existing encrypted WebLibre profile before setup runs. Combined with the migration guide for moving bookmarks and browsing habits from another browser in stages, that gives you a route between channels, but it is a route with a data-loss step in the middle, not a smooth in-place upgrade.

First launch splits into three paths, and the quick one is not reversible

The first launch screen offers three setups, and they differ in what they configure up front.

Quick Start applies the recommended defaults and installs uBlock Origin automatically. Custom Setup lets you pick search, DNS over HTTPS, layout, hardening, on-device AI and extension options before the browser is configured. Restore from Backup imports an existing encrypted WebLibre profile ahead of setup.

That third path matters for the previous section: restoring a profile is how a reinstalled build gets its data back, and it is also why the backup guidance matters.

New installations start with strict tracking protection on top of the container and tab model, together with DNS over HTTPS, HTTPS-only protection, Global Privacy Control, fingerprinting defenses and site isolation. Every one of those settings can be changed, which is the point of the Custom Setup path and of the per-site exception mechanism.

The documentation set is organized around the same lifecycle. There is a First Launch Guide explaining what each setup option does, a Privacy Check-Up for reviewing the important settings after setup, a Switching from Another Browser guide, and a set of Common Workflows for everyday and power-user tasks.

Local search over tabs, history and feeds, plus an on-device AI option

The search story is deliberately local. Instead of sending a query to a search provider for everything you type, WebLibre can search on device across your tabs, your history and your feeds. For a browser that advertises privacy defaults, keeping the query box inside the device is the coherent choice, and it also means the browser has a local index of what you have open.

The same theme shows up in the setup options, where on-device AI sits alongside search, DNS over HTTPS, layout, hardening and extension choices. The documentation does not describe what the on-device model is or which tasks it handles, so it is fair to say only that the option is offered and to check the privacy documentation before relying on it for anything sensitive.

The project also documents a threat model alongside its privacy overview. For a browser whose whole pitch is separation of identities and network paths, a written threat model is where you can see which adversaries are in scope. It is the first document to read if you are evaluating the privacy claims rather than taking them on trust.

Alpha releases, an AGPL licence, and what an upgrade costs you

The release record is short and busy. The tagged versions are v0.40.0-alpha-6 on 2026-10-02, v0.40.0-alpha-7 on 2026-10-07 and v0.40.0-alpha-8 on 2026-10-13, and the last push was on 2026-10-13. The repository is not archived.

Read those together: this is an alpha line, and an alpha in the 0.40.0 series still carries the usual cost. Settings can move, and the project itself warns that some updates may cause problems or change how features work. The upgrade path for a user is simple, installing a newer signed APK from the same channel, but the cost is that behaviour you configured may not be the behaviour you get, and a browser is exactly the software where you notice that.

On licensing, the project is AGPL-3.0 and the repository ships the license text in COPYING. AGPL-3.0 is a copyleft license, so a fork that modifies and distributes the browser, including a network use case, carries obligations you need to read in the license text itself. Anyone embedding this browser in a product or shipping a modified build should have someone qualified read COPYING and the AGPL-3.0 terms. Nothing here is legal advice, and the licence file is the only source that settles the question.

One more practical note on upgrades: a GitHub release managed by Obtainium, a Play install, and an F-Droid install all update on their own schedules, and the F-Droid one is the slowest of the three.

Editorial conclusion

Adopt WebLibre if you want a Firefox-compatible engine on Android with cookie isolation, per-container proxy routing and on-device search, and you are willing to install an alpha build. Do not adopt it if you need a stable release channel, a Chrome extension ecosystem, or a browser you can update in place from F-Droid to a signed GitHub APK. Verify three things first: that `apksigner verify --print-certs` matches the published fingerprint for your channel, that your Android version is 8.0 or newer, and that the last push was on 2026-10-13 with alpha releases under the v0.40.0 tag.

Frequently asked questions

Official sources

1. FaFre/WebLibre on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases