OpenReader is an open-source, self-hostable read-along document reader server that plays EPUB, PDF, DOCX, TXT, and Markdown documents as narrated audio with synchronized word-by-word highlighting and audiobook export, and it is built for self-hosters, tinkerers, and teams that want that capability without depending on a closed hosted service.

What it is

OpenReader is a Next.js and TypeScript application that renders documents and narrates them, keeping a single durable document timeline for audio, highlighting, and export. It was previously named OpenReader-WebUI, is licensed under MIT, and ships under the openreader repository with roughly 509 stars and 70 forks. The project lives in the TypeScript and Next.js ecosystem and depends on the surrounding OpenAI-compatible TTS ecosystem — both self-hosted servers such as Kokoro-FastAPI, KittenTTS-FastAPI, and Orpheus-FastAPI, and cloud APIs such as OpenAI, Replicate, and DeepInfra. A compute worker control plane, backed by NATS JetStream, carries the alignment and generation work.

The concrete problem it solves is turning a static document into a single seekable audio timeline that stays consistent across playback, reloads, and exports. Rather than pairing a separate text extractor with a separate TTS client and stitching the results together by hand, OpenReader keeps parsing, alignment, caching, and export inside one server. Its layout-aware parsing keeps PDF highlighting aligned to real document geometry, and its cache is reused across seeks, reloads, and audiobook export so audio is not regenerated per listener action.

Key capabilities

• Progressive background generation and playback: listening can start as soon as the first segment is ready while the worker continues generating ahead into one durable document timeline.
• Layout-aware PDF parsing with PP-DocLayoutV3 (ONNX), covering structured block detection, cross-page stitching, and geometry-based highlighting.
• Word-by-word highlighting through ONNX Whisper alignment, driven by the compute worker control plane over NATS JetStream.
• Five readable formats — EPUB, PDF, TXT, MD, and worker-converted DOCX — with generated PDF and EPUB library previews.
• Multi-provider TTS against self-hosted OpenAI-compatible servers (Kokoro-FastAPI, KittenTTS-FastAPI, Orpheus-FastAPI) or cloud APIs (OpenAI, Replicate, DeepInfra).
• Audiobook export in M4B or MP3, assembled by the worker from the same playback cache.
• Flexible backend: embedded SeaweedFS or S3-compatible storage, SQLite or Postgres, server library import, and device sync.
• Self-host friendly packaging with Docker images for amd64 and arm64, built-in auth and session support, and automatic startup migrations.

Who uses it and how

• Individual self-hosters running the Docker Compose stack on amd64 or arm64 hardware and pointing it at a local TTS provider.
• Readers who import a book library once on the server and rely on device sync to keep progress aligned between a desktop and a phone.
• Operators who split the web tier from the compute worker, deploying the front end on Vercel and running the worker separately against NATS JetStream.
• Multilingual readers who set a document language for language-aware narration and highlighting, with available languages bounded by the configured TTS provider and voice.
• Listeners who convert documents into M4B or MP3 audiobooks for offline use rather than streaming from the interface.

Getting started

The documented entry points are Docker Compose for a self-hosted run and a Vercel deployment for the front end with an external compute worker, all described at docs.openreader.richardr.dev alongside configuration guides for auth, database, object storage, and TTS providers.

How it compares

No list of paid products that OpenReader replaces is provided in these facts, and no comparable read-along reader is named among them. On the available record it stands alone in this registry.

When to use it — and when not to

A self-hoster must operate more than one process: the web application, a compute worker, a NATS JetStream path between them, a SQLite or Postgres database, and embedded SeaweedFS or S3-compatible object storage, plus whatever TTS provider is chosen. Anyone unwilling to run that set of services, or to trust document text to OpenAI, Replicate, or DeepInfra, should either stay on a fully local provider such as Kokoro-FastAPI or pick a simpler single-process reader. Weaknesses in the visible record are limited detail in the README excerpt itself and DOCX support that depends on worker conversion, so the full documentation should be checked before committing to a deployment.