Liferea: a GTK feed reader with an embedded browser inside

A mail client layout with the browser embedded

The README describes Liferea as a desktop feed reader and news aggregator that brings together the content of your subscriptions into a simple interface for organising and browsing feeds. The interface is the point of the design. Its GUI is described as similar to a desktop mail or news client, with an embedded web browser, which means the reading pane is a real browser view rather than a stripped down text renderer. That is the reason the project pulls in Mozilla Readability and a sanitiser, which is a subject for its own section. The audience is a person on a Linux desktop who subscribes to a lot of sites and wants a single window that shows a folder tree, a list of items and the article itself, in the manner of a mail client, without a service account in between.

Two version lines are being released at the same time

The release list is the first thing to look at and it needs a sentence of explanation. Three versions are recent: v1.16.15 published on 2026-10-05, v2.0.2 on 2026-09-29 and v2.0.1 on 2026-09-01. That is not a typo, and it means the project is maintaining a 1.16 line and a 2.0 line in parallel, with the older line still receiving patch releases after the newer line appeared. The repository is not archived and the last push was on 2026-10-17, so work is continuing in the tree. For an evaluator the practical consequence is that the version number alone does not tell you which lineage you get, so the changelog in the repository is the thing to read before picking a build. The topics attached to the repository include hacktoberfest, which is a hint that the project takes outside contributions during that period.

Building with meson, and the XDG_DATA_DIRS trap

The build system is meson, and the README gives the whole sequence. You configure a build directory, compile, run the tests, and install:

meson setup builddir && cd builddir
meson compile
meson test

Installing is a separate step, and translations have their own target:

meson compile liferea-update-po

meson install

There is one trap in the README that will cost you an afternoon if you skip it. If you compile with a --prefix directory that does not match $XDG_DATA_DIRS, you get a runtime error about the schema not being found, and the workaround is to set that variable before starting Liferea:

env XDG_DATA_DIRS="$my_dir/share:$XDG_DATA_DIRS" $my_dir/bin/liferea

This is a desktop application that installs a GSettings schema, so the schema has to be found at runtime the same way any other desktop component expects. Installing into the system prefix, which is what the packaged versions do, avoids the problem entirely.

Readability, DOMPurify and Handlebars in the resource pipeline

The package.json shows that Liferea is not purely a C application. Its JavaScript dependencies are DOMPurify, Mozilla Readability and Handlebars, and the installDeps script copies dompurify's purify.min.js, handlebars and handlebars.min.js and Readability.js into resources/js/vendor. The build step for updating JavaScript dependencies is npm based:

npm i
npm audit fix
npm run installDeps

The test script is eslint over resources/js/*.js, so the JavaScript is linted as part of the workflow. Read what those three dependencies do together and the design becomes clear. Readability extracts the readable article from a cluttered web page, DOMPurify sanitises the HTML that comes back, and Handlebars is the template layer used to present it. That is the pipeline behind the embedded browser: a full browser view for pages where extraction fails, a cleaned-up article view where it succeeds. It is also why the JavaScript assets are vendored into the source tree rather than fetched at runtime.

What the source tree contains

The top level layout is that of a mature C desktop application. src/ holds the C sources, resources/ holds the non code assets including the JavaScript that the npm step vendors into it, plugins/ holds the plugin directory, po/ holds the translations, opml/ holds the subscription list formats, css/ holds styling, dtd/ holds document type definitions and data/ holds the remaining packaged data. The build is driven by meson.build at the root with config.h.in for the generated configuration header, and package-lock.json and package.json sit alongside it for the JavaScript side. The presence of plugins/ is the most interesting item for a user, since it indicates the reading and fetching behaviour is not entirely hard coded, and opml/ is the file you would look at first if you want to export or import a subscription list.

Installing: a distribution package, a flatpak, or your own build

Most Linux distributions package Liferea, and the README links to repology for the version listings, so on a mainstream distribution the practical route is the package manager and there is no build step at all. There is also a flatpak package, published at flathub under net.sourceforge.liferea, which suits a system where you would rather not add the application libraries to the system. The three routes differ in what they cost you. A distribution package is the shortest path and the one the maintainer expects, since it installs the schema in the right place. A flatpak isolates the dependencies and the sandbox limits what the feed fetcher can reach on the host. Building from source with meson gives you the newest commits and the JavaScript pipeline, at the price of the XDG_DATA_DIRS wrinkle and of keeping up with a dependency set that moves.

Licence terms live in two files

The licence field on the repository says Other, described as a custom licence GitHub cannot classify, and the reason is visible in the tree: there are two licence files, COPYING and COPYING.LIB. That pairing is the usual convention for a C library plus a larger program, where the library code carries the more permissive terms and the surrounding application carries the copyleft ones. The README does not spell out the split, and it is not something to guess at. If you plan to link against or reuse parts of the source, read both files and have the boundary between the two clear before you ship. The repository also carries an AUTHORS file and a ChangeLog, both of which point to a project with a long and deliberate history rather than a rewrite.

Editorial conclusion

Liferea suits a Linux desktop user who wants a conventional three pane feed reader with article reading built in, rather than a web service or a browser extension. Skip it if you need mobile or browser only reading, since this is a local GTK application and nothing in the repository suggests a sync backend. Before adopting, decide which release line you want, since 2.0.2 and 1.16.15 were both published in September and October 2026, and if you build it yourself from a custom --prefix, set XDG_DATA_DIRS before launching or the schema will not be found at runtime.

Frequently asked questions

Official sources

1. Issues
2. lwindolf/liferea on GitHub
3. Project website
4. README
5. Releases