Nyxt: a keyboard-driven browser written in Common Lisp

A browser whose commands are Common Lisp

The README calls Nyxt a keyboard-driven web browser designed for hackers, and the project is written in Common Lisp. That combination is the whole point rather than a detail. Emacs and Vim are named as the sources of the interaction model, and the README lists familiar keybindings from Emacs, from vi and from CUA, so a Vim user is not asked to relearn a mouse-first interface from scratch. What is offered in return is extensibility in Lisp, and the repository layout backs that claim up: the tree contains a source/ directory of Common Lisp code, a libraries/ directory, and a nyxt.asd system definition file, the usual ASDF description for a Lisp application.

The intended reader is someone who treats configuration as code. The project topics sit alongside browser, common-lisp, emacs, extensible, power-user, productivity and vim, and the home page is nyxt-browser.com. This is not a stripped-down viewer for a locked-down kiosk; it is a browser where the behaviours are expected to be changed by the person using it. The README also points contributors to developer-manual.org for the developer's documentation, which signals that extension is meant to happen through a documented process rather than by patching a binary.

Fuzzy tab switching and a marking model for bulk actions

The most concrete part of the design is how tabs are reached. Nyxt switches between open tabs through fuzzy search, and the README gives the mechanics with the example of a page at https://www.example.com, where typing ele, exa or epl all match. Matching on a subsequence of characters rather than a prefix means the buffer switcher behaves the way an experienced vi user expects, without needing to know the page title in advance.

A second idea sits underneath it: multiple marking. The README states that commands can accept multiple inputs, so a single action can be applied against several objects at once, with the example of simultaneously opening several bookmarks. Marking is the difference between a browser that can open one thing and a browser you can hand a set of things. It also explains why tab search and bookmark search are described as separate features rather than one search box: the objects being searched differ, and each has its own marking semantics.

Multi tab search completes the picture. The README describes searching multiple tabs at the same time and viewing all results in a single window, then jumping quickly through open tabs to find what you need. Three layers, in other words: fuzzy matching to pick a tab, marking to act on many, and a combined result window to see across what is already open.

Bookmarks as tagged records rather than a flat list

Bookmarks in Nyxt are treated as records with metadata attached. The README says you can bookmark a page with tags, search bookmarks with compound queries, and capture more data about your bookmarks. Grouping and organising them in whatever way you like is presented as a user decision, not a fixed schema. In practice that means a bookmark is closer to an entry in a small database than to a row in a browser's address list, and compound queries are the natural consequence: if each entry carries tags, then a query can combine conditions across them.

This is where the Lisp extensibility earns its place. The tagging and querying behaviour described in the README is surface area, and the repository is a Lisp application with a libraries/ directory, so the parts of the model that do not fit your habits are the parts you are expected to change in Lisp. The trade-off is that a feature you rely on is a feature you may also have to maintain, because there is no separate extension marketplace that quietly updates itself for you.

History kept as a tree instead of a back button

Nyxt represents history as a tree that can be traversed, and the README argues that this is smarter than the forwards-backwards abstraction found in other browsers, because the tree keeps track of where you have been. The difference is concrete rather than cosmetic. A linear history records a single path through the web, so returning to a page you visited three branches ago means walking backwards through steps that are no longer relevant. A tree keeps the branches.

For people whose work involves jumping between many partially overlapping sources, this is the feature that makes revisiting cheap. It is also the feature most likely to be quiet and unremarked: nobody notices a history structure until the day they need the page they saw an hour ago from a different direction. The README documents the tree but does not describe how it is persisted or how large it can grow before it becomes unwieldy, so the practical limits are worth checking on your own data before you depend on it.

Getting Nyxt onto GNU/Linux through Flathub

The installation section is short and honest about what is finished. The README lists GNU/Linux as a supported platform, macOS and Windows as in development, and FreeBSD as unofficial. For Linux, the Nyxt team maintains one distribution channel, the Flathub listing below, and it points at repology for other distribution means, noting that the team is not accountable for their quality and asking that issues be reported to the maintainers of those packaging efforts.

The README does not spell out a command line install, so there is nothing to copy into a terminal from it. What it gives you is the address of the officially maintained Linux build:

https://flathub.org/apps/engineer.atlas.Nyxt

That listing is where a Linux user should start, since the project itself vouches for it while declining responsibility for the community packagings. On macOS and Windows you are on your own: the README marks both as in development, so expect to build from the repository rather than install a packaged release. The repository tree confirms that a source build is possible, with a makefile, an INSTALL file, a nyxt.asd system definition and a _build/ directory for compiled output.

What the repository layout says about extending Nyxt

The top-level entries describe a working Common Lisp project rather than a packaged binary. There is source/ for the application code, libraries/ for bundled dependencies, tests/ for the test suite, assets/ for images such as the ones the README embeds, and .gitmodules for vendored submodules. A .dir-locals.el file suggests Emacs users are a first-class audience, and developer-manual.org is the stated path for contributors.

There is also a licenses/ directory, but the project metadata does not name a licence, so anyone planning to redistribute Nyxt or build on it needs to read that directory directly rather than rely on a repository field. That is a licensing question rather than a legal opinion, and it is worth resolving before a team standardises on the browser.

The release history explains the pace. The release list shows 4.0.0 published on 2026-01-18, preceded by numbered pre-releases such as 4.0.0-pre-release-13 from 2025-08-01, while the last push to the repository was on 2026-10-17 and the README states plainly that Nyxt is under active development. A browser that ships pre-releases for months and then a stable version is a project with a real release process, and a reader should expect some churn between tagged versions.

Where the keyboard-first model stops paying off

Two limits follow directly from what the README says. The first is platform reach: Linux is the only platform with a maintained package, macOS and Windows are still in development, and FreeBSD is unofficial. The second is that Nyxt competes on a different axis from mainstream browsers. The alternative approach most people already use is a graphical browser extended through a sandboxed extension package, where behaviour is added from outside the browser process and the renderer stays the primary interface. Nyxt inverts that: the interface is the keyboard, and behaviour lives in Lisp inside the application, so there is no equivalent of installing a JavaScript extension that someone else updates on your behalf.

That inversion buys power and costs convenience. Anyone who depends on a specific commercial extension, on account sign-in flows that assume a conventional chrome, or on an accessibility path designed around a visual interface will find those areas thinner here, and the README does not promise otherwise. On the other hand, the Lisp surface is exactly what a terminal-bound engineer can shape to fit an existing workflow, and the absence of a mouse-first chrome is the point rather than a missing feature.

Editorial conclusion

Nyxt suits engineers and writers who already live in Emacs or Vim and want browser behaviour to be ordinary Lisp they can edit. It is a poor fit if you need a polished Windows or macOS build today, if your work depends on browser extensions you cannot rewrite, or if you are unwilling to read a manual written outside the README. Before committing, install the Flathub build on GNU/Linux and confirm that its keybindings and its Lisp configuration surface fit your existing workflow.

Frequently asked questions

Official sources

1. atlas-engineer/nyxt on GitHub
2. Issues
3. Project website
4. README
5. Releases