Thorium Reader: an EPUB 3 desktop app built on Readium Desktop

What Thorium Reader is for, and who it is not for

Thorium Reader is a desktop EPUB reading application for Windows 10 and 10S, macOS and Linux. The README describes the workflow plainly: you import e-books from a directory or an OPDS feed, then read with adjustable layout, a table of contents or page list, and bookmarks. The repository topics list epub, epub3, audiobook, lcp and opds, so the target is standards-compliant publications rather than a proprietary store format.

The audience is narrower than "anyone who reads ebooks". The README states that care is taken to ensure accessibility for visually impaired people using NVDA, JAWS or Narrator. That is the differentiating requirement. If your reading setup depends on a screen reader on Windows, or on a large-screen layout that reflows, this project was built with that in mind. If you want a phone app, the README lists Windows, macOS and Linux only, and the related searches for Android, iPad and iOS have no corresponding platform in the documentation.

The application is free, with no ads, and the README states no private data flows anywhere. That claim sits next to a build-time telemetry path described further down, so read both before treating it as an absolute.

How the Electron, React and Redux stack fits together

The package.json declares name EDRLab.ThoriumReader, version 3.5.2-beta.1, type commonjs and main dist/main.js. The declared technologies are TypeScript, Electron, React, Redux, Saga and i18next. The build is split across separate webpack configs: webpack.config.main.js, webpack.config.preload.js and webpack.config.renderer-library.js, with a shared webpack.config.js. That three-way split matches Electron's process model, where the main process, the preload bridge and the renderer are bundled separately.

The repository layout reflects the same separation: src/ holds application code, test/ holds Jest tests, projects/ contains sub-projects including a PDF annotations harness with its own Playwright config, and native-node-addon-windows-registry/ is a native addon. The reading engine itself is not in this repository. The README states the application is based on the open-source Readium Desktop toolkit, so publication parsing, rendering and navigation come from that dependency rather than from code you can patch here.

Localisation is also external. Since February 2025 the project uses Weblate, and the README lists 28 locales including English, French, German, Japanese, Simplified and Traditional Chinese, Arabic and Georgian. Translation status is published as a Weblate widget rather than tracked in the repository.

Installing Thorium Reader from source on Windows, macOS or Linux

The README gives prerequisites of NodeJS 22 and NPM 11, checkable with node --version and npm --version. It warns that the NPM bundled with the NodeJS installer may be older than required and suggests updating it. Dependencies install with npm ci rather than npm install, with scripts and git-root restrictions applied.

npm ci --ignore-scripts --foreground-scripts --allow-git=root

If that fails on a Divina player SHA integrity mismatch, the README offers a repair path: run the package-lock patch script and grep the lockfile for divina-player-js to confirm the entry.

node scripts/package-lock-patch.js && cat package-lock.json | grep -i divina-player-js

The Electron binary is no longer fetched by a postinstall hook. The README states this is now a manual step, and gives the command that sets up the Electron binary for the current platform.

cd node_modules/electron && DEBUG=@electron/get* force_no_cache=true node install.js && cd -

After that, development runs with hot reload and web inspectors. A quick variant bypasses TypeScript checks.

npm run start:dev

A production-mode start uses npm start. Installers are produced per platform with npm run package:win, npm run package:mac or npm run package:linux, and the README points at the GitHub Actions workflow YAML for the Intel and ARM build matrix. Code signing has its own wiki page, not a README section.

LCP protection: the open source build stops at Basic Encryption Profile

This is the sharpest limitation in the documentation. Thorium Reader supports LCP-protected publications through a component that the README states is not available in this open-source codebase. Compiled from the open source code without that additional production-grade library, the application can only load publications protected with the LCP "Basic Encryption Profile", for example licences generated by the open-source LCP server written in Go without the patch enabling production-grade LCP Encryption Profiles.

So the repository you can clone is not the same binary that a library or a commercial distributor would ship. If you are evaluating Thorium Reader for a lending service that issues production-grade LCP licences, the open source build is the wrong artefact to test against, and the README does not document where the additional component comes from. That gap is worth resolving before any pilot, because it changes what you can verify locally.

The repository does contain customization-profile-public-key-pair.js and a tsconfig-customization.json, which suggests a customization profile mechanism, but the README excerpt does not explain how a profile is applied or what it unlocks.

Telemetry, proxies and the privacy claim

Firebase and GA4 Measurement Protocol support is configured at build time through environment variables consumed by webpack.config-preprocessor-directives.js. It is disabled by default, and the README states emitted events still respect the in-app "Disable telemetry measurements" setting. Boolean flags are enabled by any value except 0 or false.

The variables are THORIUM_FIREBASE_ENABLED, THORIUM_FIREBASE_DEBUG, THORIUM_FIREBASE_MEASUREMENT_ID, THORIUM_FIREBASE_MEASUREMENT_PROTOCOL_API_SECRET, THORIUM_FIREBASE_MEASUREMENT_PROTOCOL_ENDPOINT, THORIUM_FIREBASE_MEASUREMENT_PROTOCOL_DEBUG_ENDPOINT and THORIUM_FIREBASE_MEASUREMENT_PROTOCOL_QUEUE_SQLITE_ENABLED. The measurement ID and API secret are required when telemetry is enabled, and the README says to keep the secret in main-process build environments only. The queue can use SQLite instead of a JSON file store.

That is a build-time switch, not a runtime preference, which matters for anyone shipping a binary: a distributor who enables it hands the reader a build where telemetry exists, and the in-app setting is the only user-facing control. The README's "no private data flowing anywhere" line should be read against this configuration surface.

Network behaviour is also configurable through HTTPS_PROXY, HTTP_PROXY and NO_PROXY, in the form http://proxy.example.com:8080, with NO_PROXY taking a comma-separated list of hostnames or IP addresses. The README notes the proxy-agent package from TooTallNate is used.

Where Calibre or a browser reader is the better choice

Calibre is the obvious alternative, and the difference is architectural rather than cosmetic. Calibre is a library manager first: conversion between formats, metadata editing and device transfer are central, and its reader is one component of that. Thorium Reader does not convert formats. It imports EPUB and audiobook publications from a directory or an OPDS feed and renders them, delegating parsing and rendering to Readium Desktop.

If your problem is a 4,000-title collection in mixed formats that needs normalising before it can be read at all, Calibre addresses that problem and Thorium Reader does not. If your problem is that a screen reader user cannot navigate a publication's structure, or that you need to consume an OPDS catalogue with LCP-licensed titles, Calibre's conversion pipeline is not the relevant capability and Thorium Reader's accessibility and OPDS work is.

A browser-based reader is the other comparison. It needs no install and runs anywhere, which is why the related searches include an online variant. The trade-off is the opposite of Thorium's: a browser tab cannot manage a local library, cannot integrate with an OS-level screen reader the way an Electron app can, and cannot hold an LCP licence store on disk in the same way.

Maintenance, licensing and what a fork costs you

The repository is not archived, and the last push was on 2026-09-23. Recent releases are automated test builds tagged latest-windows-intel, latest-windows-arm and latest-macos-intel, all dated 2026-09-23, which indicates a continuous packaging pipeline rather than periodic hand-cut releases. The package version is 3.5.2-beta.1, so the current line is a beta.

The licence is BSD-3-Clause. That is permissive: it allows redistribution and modification with attribution and without a copyleft obligation on your changes. It also means no warranty, and it does not grant rights to the separate LCP component that the README says is not in this codebase. If you plan to ship Thorium Reader inside a product, the licence question you actually need answered is about that component, not about the BSD text. This is not legal advice; have counsel read the LCP arrangement.

Upgrade cost is dominated by the toolchain, not the application code. The engines field requires Node >=22.0.0 and npm >=11.0.0, and devEngines pins the package manager at >=12.0.2 with onFail set to error, so a mismatched runtime stops the build rather than warning. The Dockerfile builds on ubuntu:20.04 and installs Node 24.x from NodeSource, and its own comment notes that the Ubuntu 20.04 runner image will be fully unsupported by April 1, 2025. Anyone maintaining a containerised build inherits that base-image decision. The manual Electron install step is another recurring cost: it is a documented deviation from the usual postinstall flow, and it must be repeated when node_modules is rebuilt.

Editorial conclusion

Adopt Thorium Reader if you need a desktop EPUB 3 reader with screen reader support and OPDS import, and you are willing to build it from the develop branch with NodeJS 22 and NPM 11. Do not adopt it if you need an Android, iPad or iOS client, or if you need production-grade LCP decryption from the open source code alone, because the README states that component is not in this codebase. Before committing, verify the Node and NPM versions, run the manual Electron install step, and check whether the LCP profile your licences use is Basic Encryption Profile or a production-grade profile.

Frequently asked questions

Official sources

1. edrlab/thorium-reader on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases