# qutebrowser: a keyboard-driven browser where the config file is the interface > qutebrowser is a GPL-3.0 browser built on Python and Qt with a minimal GUI and vim-style keybindings. It is for people who want to drive the web from the keyboard and keep their setup in a text file, not for anyone who wants a Chrome replacement with an extension store. **qutebrowser/qutebrowser** — A keyboard-driven, vim-like browser based on Python and Qt. - Repository: https://github.com/qutebrowser/qutebrowser - Website: https://www.qutebrowser.org/ - Stars: 11,713 · Forks: 1,134 - Language: Python - License: GPL-3.0 - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/qutebrowser-qutebrowser ## Who qutebrowser is actually for qutebrowser is a keyboard-focused browser with a minimal GUI, based on Python and Qt, licensed under the GPL. The README names its inspirations directly: dwb and Vimperator/Pentadactyl. That lineage tells you the target reader. Someone who already reaches for hjkl to scroll, who wants to open a link by typing a hint label instead of aiming a mouse, and who would rather edit a Python file than click through a settings dialog. The GUI is deliberately thin. There is no toolbar of extension icons, no account sync, no bundled password manager to configure. What you get instead is a command line inside the browser. Commands such as :open, :set and :report are typed into a prompt, and the same commands can be bound to keys or called from configuration. For a sysadmin or developer who spends the day in a terminal, the mental model transfers without much friction. For everyone else, the first ten minutes are hostile: there is no address bar in the conventional sense, and the documentation is the primary interface. The project is honest about its funding situation. The README states that the primary maintainer, The-Compiler, works part-time on qutebrowser funded by donations, and asks for support through GitHub Sponsors or Liberapay. That is a maintenance signal worth reading plainly: this is not a corporate browser with a paid team behind it. It is a long-running project with a single dominant maintainer and donation funding, and the release cadence reflects that. ## Python, Qt and the WebEngine underneath The architecture is a Python application driving Qt widgets. The README lists the hard requirements: Python 3.10 or newer, Qt 6.2.0 or newer (or 5.15.0 or newer), PyQt 6.2.2 or newer for Qt 6, plus jinja2 and PyYAML. The Qt modules required include QtCore, QtQuick, QtSQL, QtDBus and QtOpenGL. On macOS, pyobjc-core and pyobjc-framework-Cocoa are also required. The rendering engine is the part people ask about most, and the README answers it: the default backend is QtWebEngine, which is based on Chromium. The alternative, QtWebKit 5.212, is documented as not recommended because of known security issues. The README quotes the QtWebKit releases page warning that the release is based on an old WebKit revision with known unpatched vulnerabilities, and advises avoiding untrusted sites and sensitive data. In practice this means qutebrowser is Chromium-based for rendering while being a completely separate application around it. You get Blink's page compatibility; you do not get Chrome's extension system, and you do not get Chrome's release schedule for engine security fixes, since those arrive through your QtWebEngine package. Configuration and data flow follow the same philosophy. Settings, keybindings and the session live in text files, and the :set command applies configuration at runtime. The README points at doc/install.asciidoc for platform instructions and doc/faq.asciidoc for common questions. Because the browser is a Python program, the configuration layer is Python too, which is either the best or the worst part of the project depending on your temperament: you can compute values, import modules and share snippets, and you can also break your browser with a syntax error in a file it reads at startup. ## Installing qutebrowser and a first real session The README does not enumerate per-distribution commands; it points to the GitHub releases page for downloads and to doc/install.asciidoc for detailed instructions per platform. The search terms people use around this project are heavily distribution-specific (Arch, Ubuntu, Windows, macOS), and the honest answer is that the install path differs by platform enough that the project keeps it in a separate document. Check that document for your system rather than assuming a single command works everywhere. The README does not spell out a package manager invocation, so the reliable starting point is the install documentation it links to. What the repository does give you is the Python-side dependency set, pinned in requirements.txt and regenerated by scripts/dev/recompile_requirements.py. Those pins are adblock, colorama, Jinja2, MarkupSafe, packaging, Pygments and PyYAML, and the Qt bindings themselves are not among them: ```bash pip install -r requirements.txt ``` After the first launch, the command to run is :version. It reports the qutebrowser version, the Qt version and the QtWebEngine version in use, which is the fastest way to confirm that you are on the Chromium-based backend rather than a leftover QtWebKit install. Two other commands are worth knowing on day one: :set opens the settings prompt for changing a value at runtime, and :report collects diagnostics you can attach to a bug report, which the README lists alongside the GitHub issue tracker and the mailing list as the supported reporting channels. Security issues go to security@qutebrowser.org rather than the public tracker. ## Ad blocking, the optional dependency that matters qutebrowser does not ship an extension store, so the usual way of adding a content blocker does not exist. The README lists adblock as an optional dependency described as being for improved adblocking using ABP syntax. That phrasing is precise and worth parsing: it is optional, it is for improved blocking, and it uses Adblock Plus filter syntax. Installing the Python package is a prerequisite for that path, not the whole story. This is the clearest example of a trade-off in the project. A Chromium-based browser without the Chrome extension APIs means filter lists must be handled by qutebrowser itself or by the host-file and DNS approaches users bring from outside. The upside is that there is no extension permission model to audit and no third-party extension code running inside your browser process. The downside is that anything that only exists as a browser extension, whether a password manager integration, a reader-mode add-on or a site-specific helper, has no direct equivalent. The README does not claim otherwise. If ad blocking is the deciding factor for you, verify it before adopting rather than after. Install the adblock package, confirm the ABP-style filtering works on a site you know is heavy with ads, and check whether your preferred filter list format is supported. The README points to the package but does not document the full filter-list workflow, so the project documentation is the place to look for the details. ## Where qutebrowser is the wrong tool The first limitation is the extension ecosystem, and it is structural rather than a missing feature. qutebrowser is not Chromium and not Firefox, so Chrome Web Store and Firefox add-on packages do not run in it. If your workflow depends on a specific extension, that dependency is a hard stop, and no amount of configuration will substitute for it. The second is engine update latency. Rendering comes from QtWebEngine, which means security fixes for the engine arrive through your Qt packages, not through qutebrowser's own release channel. On a distribution that lags on Qt updates, the gap between a Chromium security release and the version your browser runs is set by your distro maintainers. That is a real consideration for anyone treating this as a hardened daily driver, and the README's own warning about the QtWebKit alternative shows the project is aware of how much the backend choice matters. The third is configuration fragility. Because configuration is code, a mistake in a config file can prevent startup, and the recovery path is editing files rather than clicking a reset button. The README does not document a rollback mechanism for a broken configuration. If you are not comfortable debugging a Python traceback from a browser launch, this is friction you will meet early. Finally, performance expectations deserve calibration. The project describes itself as keyboard-focused with a minimal GUI, not as the fastest renderer available. If raw page-load speed on JavaScript-heavy sites is your primary criterion, a browser that wraps QtWebEngine is unlikely to beat the upstream Chromium it depends on, and the search interest in whether qutebrowser is fast or lightweight is better answered by measuring on your own hardware than by taking the project's word for it. ## qutebrowser versus Firefox and Vimium-style setups The natural alternative for most people considering qutebrowser is Firefox with a keyboard-navigation extension such as Vimium, or Chrome with the same class of add-on. The difference in approach is not cosmetic. With Firefox plus an extension, you keep the full browser platform: extension APIs, a settings UI, profile sync, and Mozilla's engine update cadence. The keyboard layer is a guest inside someone else's browser, and it can only do what the extension APIs permit. qutebrowser inverts that relationship. The keyboard and command layer is the browser, and the rendering engine is the component underneath it. That means the command set is not bounded by an extension API, configuration is a first-class Python surface rather than a JSON blob in an extension's storage, and the whole application is auditable source under the GPL. It also means you give up everything the host browser provided for free: the extension catalog, the settings GUI, the account system, and the guarantee that engine security patches land on the browser vendor's schedule. A second alternative worth naming is simply staying in the terminal with a text browser. That is a different trade-off again, since it drops JavaScript rendering entirely. qutebrowser's position is between the two: full modern web rendering via QtWebEngine, with a terminal-like interaction model on top. If you want the interaction model but not the rendering, the lighter option exists; if you want the rendering and not the interaction model, Firefox is the safer default. ## Licence, maintenance and upgrade cost qutebrowser is licensed under GPL-3.0, and the README repeats that it is free software under the GPL. For individual users this has no practical consequence. For anyone considering embedding, bundling or shipping a modified qutebrowser inside a product, the GPL's copyleft terms apply to distributed derivative works, and the repository's LICENSE file plus the project's own documentation are the sources to read. This article is not legal advice; if distribution is on your roadmap, get a real opinion rather than inferring from a licence identifier. Maintenance is donation-funded and centred on one maintainer, as the README states plainly. The latest release listed is v3.7.0 from 2026-04-03, following v3.6.3 in late 2025 and v3.6.2 shortly before it. The repository is not archived and the last push was on 2026-09-21, so the codebase is being touched, but the funding model is the thing to weigh: a project sustained by donations and part-time work has a different risk profile from one with a commercial backer. Upgrade cost splits in two. The Python side is pinned in requirements.txt, which is regenerated by scripts/dev/recompile_requirements.py, so dependency bumps are a deliberate step rather than an automatic one. The heavier side is Qt and QtWebEngine, which live outside that file and are governed by your distribution or your Qt installation. A Qt major upgrade is the event most likely to break a working setup, and the README's requirement of Qt 6.2.0 or newer with the listed modules is the checklist to run against before upgrading. Keep your configuration under version control; it is the part of the upgrade that only you can fix. ## Conclusion Adopt qutebrowser if you already live in vim or a tiling window manager and want your browser state in plain text files under ~/.config/qutebrowser; skip it if you depend on the Chrome Web Store or need the fastest JavaScript rendering. Before committing, check that your distribution ships Qt 6.2.0 or newer with QtWebEngine, run :version after the first launch, and confirm that the adblock package is present if you want ABP-style filtering. ## FAQ ### What is qutebrowser based on? It is a Python and Qt application, and by default it renders pages with QtWebEngine, which the README describes as based on Chromium. A QtWebKit backend exists but the README states it is not recommended because of known security issues. ### Does qutebrowser have Adblock? The README lists adblock as an optional dependency for improved adblocking using ABP syntax, so it is a package you install rather than a built-in feature. The README does not document the full filter-list workflow. ### Is qutebrowser lightweight? The README describes it as a keyboard-focused browser with a minimal GUI, which applies to the interface rather than the engine. Rendering runs through QtWebEngine, so memory use depends on the QtWebEngine build your system provides. ### How do I install qutebrowser on Arch? The README does not give distribution-specific commands and instead points to doc/install.asciidoc for platform instructions. On Arch the package is named qutebrowser and pulls in the Qt and Python dependencies listed in the README. ### Is qutebrowser safe? The default QtWebEngine backend is based on Chromium, but engine security fixes arrive through your Qt packages rather than through qutebrowser releases. The README explicitly warns against the QtWebKit alternative because of known unpatched vulnerabilities. ## Sources - [License: GPL-3.0](https://github.com/qutebrowser/qutebrowser/blob/main/LICENSE) - [Project website](https://www.qutebrowser.org/) - [qutebrowser/qutebrowser on GitHub](https://github.com/qutebrowser/qutebrowser) - [README](https://github.com/qutebrowser/qutebrowser/blob/main/README.md) - [Releases](https://github.com/qutebrowser/qutebrowser/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/qutebrowser-qutebrowser