Offline by design

Most privacy policies are promises about behaviour: we collect this, we never sell that, trust us. Ours is mostly a statement about plumbing. The app is a single HTML file. It has no account system, no backend, and no telemetry. It uploads 0 bytes — not few, none — because there is nowhere for bytes to go. This piece is about that architecture as an engineering decision: why reading data deserves it, and what it costs us to keep.

The distinction between promise and plumbing is the whole argument. A conventional app that pledges not to look at your data is asking you to trust a behaviour, continuously, through every acquisition, pivot and breach in its future. An offline reading app that has no server cannot look, in the way that a bicycle cannot leak petrol. The guarantee is structural. You can verify it yourself with the network tab of your browser open: load the file, read a book, watch nothing leave. We can make that invitation precisely because we know what you will see.

Working offline follows for free. Once the file is loaded there is nothing to phone, so an aeroplane, a tunnel or a dead connection changes nothing about how the app behaves. Offline is not a mode we built and maintain beside an online mode; it is the only condition the software knows. The same is true of being a reading app with no account: sign-in is not a hurdle we removed, it is a concept the codebase does not contain.

The single-file decision is the discipline that keeps the rest honest. A codebase that is one HTML document cannot quietly grow a login screen or a background beacon; every capability has to fit inside the page you already have, and every temptation to reach outward is visible in the diff. It also makes the app inspectable in a way multi-service products never are — the entire program is a file you can open in a text editor, and the claim of no telemetry is falsifiable by anyone with the patience to search it.

What you read is who you are

Why go this far for a reading tool? Because reading data is quietly among the most intimate data there is. A list of what someone reads — and lingers on, and abandons, and returns to — sketches their health worries, their politics, their faith and doubts, their finances, their marriage, the diagnosis they have not told anyone about. Librarians understood this generations before software did, and fought for the confidentiality of borrowing records on exactly these grounds. A reading machine sees more than a borrowing record does. It sees pace, hesitation, the passage you ran four times.

Our app also asks for documents, not just titles — the PDF of your mortgage offer, the report from the specialist, the manuscript you have shown nobody. Files like that should not transit anyone’s server as the price of being read comfortably. So they do not transit ours; we have made sure we do not have one. Everything is parsed on-device: PDF through pdf.js, Word through mammoth.js, EPUB, HTML and plain text alongside, all in the browser’s own sandbox. The document is opened where it already lives and nowhere else. The mangling that PDFs inflict on this process is real and is its own essay — the PDF problem — but it is at least a private mangling.

The parts that were hard to keep local

A static page that shows words is trivially local. The app is not trivial, and each capable subsystem was a fresh temptation to add a server. The voice is the clearest example: text-to-speech is normally a cloud API, your sentences shipped out, audio shipped back, a log written somewhere in between. Ours is KittenTTS nano, a 15-million-parameter open-weight neural voice that runs in the browser itself, with eight voices, able to lead the pace or follow it. The full story is in a voice that never leaves the device, but the architectural point belongs here: the moment the voice went remote, every sentence you read aloud would have become a server log with our name on it.

The icon system posed the same temptation in a different shape. Choosing an image by a word’s sense — telling the river bank from the lending kind by scoring context cues in the surrounding window — is exactly the kind of task current fashion sends to a cloud model. It stays on-device, resolved through local tiers, with the library tier caching any fetched icon after one fetch so that even that traffic is not a running commentary on your text. Words are never sent out to be understood. How far purely local disambiguation can actually get, and where it falls short of what a large server model would manage, is treated honestly in semantics on device.

We cannot lose, sell, leak or be subpoenaed for what we never receive.

The structural guarantee

What the constraint costs us

It is worth saying that none of this required heroics so much as refusals, made early and then defended. Browsers in 2026 are extraordinarily capable machines: they parse binary formats, run neural networks, cache assets for offline use and sandbox the lot. The unusual part of an offline reading app is not the engineering ceiling, it is declining the conveniences that a server would make cheap. Each subsystem above exists in a simpler, better-resourced server-side version that we looked at and turned down. The next section is the bill for those refusals.

An architecture is only honest if its costs are stated by the people who chose it, so here are ours, in ascending order of how much they hurt. None of them is hypothetical. We pay each one today.

• No cloud sync in the free tier. With no backend, your library and history live in one browser on one machine. Move devices and nothing follows you. Membership adds sync, and it is the one place we bend the architecture — deliberately, for those who opt in, never as a default.
• Model sizes bounded by the browser. The voice is 15 million parameters because that is what loads and runs acceptably on an ordinary machine inside a browser tab. A server voice could be orders of magnitude larger and sound it. Every on-device model we ship is the small end of its family, chosen under a memory budget we do not control.
• No server-side rescue. When something breaks — a malformed EPUB, a corrupted store, a browser update that changes behaviour under us — there is no backend where we can see the failure, patch it centrally or recover your data. Support means asking you to describe what we cannot observe. Telemetry would make our bugs easier to fix; we fix them the slow way instead.
• No aggregate learning. We cannot study usage to improve defaults, tune the resolver or rank icons by what readers respond to, because we do not know what readers do. Design decisions that competitors make with dashboards, we make with reasoning, small local tests and published guesses.

The bet underneath

It would be tidy to end by declaring this architecture obviously correct, but the honest framing is that it is a bet with a losing side we can describe. The industry’s standard shape — account, backend, telemetry — exists because it genuinely delivers things users like: seamless sync, effortless recovery, features tuned by observed behaviour. We forgo those, and some readers will rightly choose a competitor because continuity across five devices matters more to them than the location of a parser. That is a reasonable weighing of costs, and we would rather say so than pretend the trade has no other side.

Our side of the bet is that reading is a special case — that the record of what a person reads is close enough to the person that the default should be silence, and that a tool asking to sit inside your attention for hours should be able to prove, not promise, that it is not taking notes. One file, no account, nothing sent. The proof is the architecture, and the architecture is the product.