Dooble is a Qt WebEngine browser that keeps its whole feature set in 46,147 lines

A browser defined by its smallness rather than its feature set

Dooble describes itself as a minimal, scientific and stable Web browser, and the project description is unusually blunt about the intent: minimal, cute, unusually stable, and available almost everywhere.

The number that anchors the whole design is 46,147 lines of source. For a browser, that is a small codebase, and it is possible because Dooble does not implement a rendering engine. It sits on Qt WebEngine, and the feature list names Qt LTS and a Qt-only dependency as two of its characteristics. Everything else in the list is built on top of that single dependency.

The scientific angle is the differentiator. Among the listed capabilities you find native graphing of data for scientific studies, and the tree confirms this is a real code path rather than a slogan: there is a Charts directory, a Data directory and a Tools directory alongside Source, UI and Translations. A user who downloads a dataset can plot it in the browser rather than exporting it to a separate analysis tool.

The rest of the feature list is broad for something this small. Anonymous tab headers, an application lock, basic themes, custom search engines, custom style sheets, favorites, a floating digital clock, a floating minute history window, a JavaScript console, many private windows, multiple private instances including downloads, portable Windows builds, Gopher support, and per-domain JavaScript disabling. The domain blocker for restricting sites is there too.

A separate line in the list is worth pausing on: Peek-a-boo, described as zero-script. That is a rendering mode, and it is the sort of feature that only makes sense in a browser whose own code is small enough to keep entirely in view.

Running on a fanless dual-core and on Raspberry Pi OS

The platform list is long and includes several operating systems that most browser projects have quietly dropped: FreeBSD, Linux, MacOS, OS/2, OpenBSD, PiOS and Windows. OS/2 and OpenBSD in the same sentence as MacOS and Windows tells you something about the intent, which is a browser that keeps building where other projects have stopped.

The performance claim is stated with unusual specificity: functional on a dual-core 1.0 GHz fanless computer, and great for ancient hardware. That is a real engineering constraint rather than a marketing phrase, because a Qt WebEngine browser is carrying a full Chromium content engine under the hood, and the interesting part is that the rest of the shell does not add much weight.

Raspberry PiOS is called out on its own in the list, alongside Apple Silicon, which suggests the two common non-x86 targets are treated as first class. The tree backs up the multi-platform claim in the usual autoconf-and-qt way: a dooble.pro project file for Qt Creator, a dooble.sh script, a dooble-version.bash script, a README.VERSION file, and separate Distributions and Contributions directories. There is also a Translations directory, so the browser has a localisation story, and a qtwebengine_dictionaries directory, which is the usual place to drop spell-check dictionaries for a WebEngine-based application.

The Images and Icons directories hold the visual assets, and the Documentation directory is where the actual manual lives, since the README itself is a feature list rather than a manual.

Per-domain JavaScript control and a domain blocker

The control features are what separate Dooble from a minimal browser that merely renders pages. Two of them are clearly aimed at people who browse untrusted content on purpose.

The first is disabling JavaScript at the domain. Rather than a global switch, the granularity is per site, which is the behaviour you want when you are reading a page on a forum you distrust but still want the rest of your session to work normally. The second is domain restrictions, called a blocker in the feature list, which is a filter list rather than a per-site toggle. One is a decision you make in the moment, the other is standing policy.

The JavaScript console sits alongside these, so a script can be inspected when you choose to let it run. That combination is coherent: scripts off by default for a given domain, on when you need to debug, and a console to debug with.

The privacy side is built from small named features rather than one big claim. Anonymous tab headers change what a page sees about the tab it lives in. The cookie consumer is described simply as consuming cookies, and combined with many private windows and multiple private instances, including separate instances for downloads, it points at a browser that treats cookie state as something you manage per window rather than a shared global pool. The application lock is a separate mechanism again, protecting the running application rather than a browsing session.

Native graphing and the charts and data directories

Native graphing of data for scientific studies is the feature that gives the project its name, and it is worth understanding what the tree says about how it is built.

There is a Charts directory at the top level, separate from Source and UI. That separation suggests the graphing is a distinct subsystem rather than a page rendered by the web engine. Alongside it sit a Data directory and a Tools directory, which in a project of this shape usually hold the data formats the browser can read and the helper programs that convert between them.

The practical payoff for a researcher is a workflow without export. Data arrives as a file, the browser reads it directly, and the result is a plot rather than a CSV that has to be handed to a statistics package. For a scientific workflow that is a meaningful convenience, and for a browser that runs on a 1.0 GHz fanless machine it is also a reason not to install a second application.

What the documentation does not establish, and what you would have to check in the Documentation directory or the Charts sources, is which data formats the plotting supports and whether the charts are interactive or static images. The feature list only claims native graphing of data for scientific studies, so treat the format coverage as unverified until you read the source.

Original AES-256 and Threefish-256 implementations, and why that cuts both ways

Among the more unusual entries in the feature list is original implementations of AES-256, Threefish-256. Original here means written for this project rather than taken from a library, and for a project that advertises 46,147 lines of source, that is a large claim to make in-house.

Threefish-256 is the cipher from the Skein hash family, and it is a block cipher designed with performance in mind on 64-bit platforms, so pairing it with AES-256 covers both a mainstream and a portable choice. Whether Dooble actually uses both for anything, and for what, is not stated in the feature list, and the feature list does not say which data these ciphers protect.

There is a real trade-off here that the project does not spell out. Hand-rolled ciphers are the classic source of subtle bugs, and an audited library implementation is normally the safer choice even when it adds a dependency. A browser that prides itself on having a single dependency and a small, readable codebase is making a deliberate trade, but you should read the implementations before you rely on them for anything, and you should check whether the code they protect is the session data, the private window contents or the saved data.

Given that the Documentation directory is referenced from the tree, that is where a description of the storage format and its encryption would be expected to live.

Where Dooble is the wrong tool

The first wrong-tool case is extension ecosystems. A browser with a Qt-only dependency and a hand-written feature set does not come with a modern extension API, and nothing in the tree suggests a plugin mechanism. If your workflow depends on an ad blocker, a password manager, a reader mode or a scripting extension, you will not find it here.

The second case is a developer who needs a browser to inspect. The JavaScript console exists, but a browser without developer tools for the DOM, the network panel and the storage inspector is not a debugging environment. For a project whose stated audience includes people reading untrusted pages, that is an unusual gap, and it is one the small codebase explains.

The third case is anyone planning to build from source. The repository README is a feature list. It contains no build instructions, no dependency list beyond the mention of Qt and WebEngine, and no configure step. The build knowledge is in the Documentation directory, the dooble.pro file and the Qt directory, and the Distributions directory holds the packaged builds. A contributor picking this up will be reading the source tree and the documentation rather than following a README.

The right comparison is not a mainstream browser but another minimal browser. The difference in approach is that Dooble's distinguishing features are the scientific graphing, the per-domain script control and the deliberately narrow feature set, where the typical minimal browser trades features for a simpler interface and leaves data analysis to external tools. Dooble tries to cover both in one binary, which is a stronger claim and a harder one to keep true across a long release history.

Editorial conclusion

Dooble suits a researcher or a tinkerer who wants a browser that runs on an old machine, blocks domains, disables JavaScript per site and plots downloaded data without extra software. It does not suit someone who needs a mainstream browser feature set, a scripting API extension ecosystem, or a documented build from source. Before adopting, read the Documentation directory and the README.VERSION file in the tree, and note that the last push to the repository was on 2026-10-20, with version 2026.10.17 tagged shortly before it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. textbrowser/dooble on GitHub