Nobody writes EPUB
EPUB is everyone's export format and nobody's native medium.
That's a strange fate for a format this good. Well established as the way novels get distributed, EPUB 3 is quietly a general-purpose container for durable documents: built from the same stuff as web pages, readable by screen readers out of the box, able to carry audio and video, working with no internet connection, and standardized by the same people who standardize the web. It could be the format for documentation that needs to be accessible, editable, archivable, and readable in ten years. It visibly isn't. (And no, this isn't about DRM — the copy-protection stigma belongs to the bookstores; documentation created for personal use needs no protection.)
Here's my thesis about why.
Four tools, one failure
Look at how EPUBs actually get made. Every tool that produces one has a primary purpose that isn't EPUB.
InDesign is professional page layout. Word, Docs, and Pages are word processors with print in their bones. Pandoc is format conversion — a command-line tool that turns one kind of file into another. Sigil and Calibre's editor are raw XML surgery.
The primary purpose leaks. InDesign's EPUBs smell like print spreads. Word's carry decades of style soup. Pandoc, by design, treats EPUB as a destination — something produced at the end of the line and never touched again. Sigil makes you the format's mechanic rather than the document's author.
The common consequence: the EPUB is always the last step, never the starting point. No tool treats the book itself as the real document — the one you open tomorrow to keep working — so the format never develops an authoring culture, only an export-then-tweak culture.
"A website in a file" keeps dying
If you doubt the potential is real, look at how many times the industry has reinvented this web package format and seen it die.
iTunes LP: dead. Apple's .webarchive: proprietary, one browser. MHTML: perpetually half-deprecated. Mozilla Archive Format: dead. Each one was reaching for the same thing — a self-contained bundle of web content you could hand to someone as a single file.
The format they were all reaching for exists now, and it's structurally boring in the best way: a zip file of web pages with a packing list inside. It's on your e-reader right now.
One distinction worth being precise about: this is the authored-document case, not the captured-page case. The web-archiving community has living formats — WARC, WACZ — and they're good at what they do, which is snapshotting pages that already exist. The claim here is not that EPUB replaces web archiving. It's that EPUB is the authored-document case everyone forgot.[1]
The incumbent
For durable offline documentation, the real competitor isn't any web archive format. It's PDF.
The comparison is structure versus snapshot. A PDF freezes a page: every line break, every font size, every margin, fixed forever at the moment of export. An EPUB preserves the document's structure — headings, sections, figures, emphasis — which is what reflow, font scaling, screen readers, dark mode, and small screens actually need. A PDF looks perfect on the machine (or page) it was made for. An EPUB adapts to the machine it lands on.
The concession has to be honest, though: PDF's killer feature is that it opens everywhere on double-click. An EPUB needs a reader app. That distribution wall is real — no browser opens .epub natively — and it's EPUB's adoption tax. This essay doesn't pretend otherwise.[2]
But the concession is narrower than it looks. A PDF is finished the moment it's made — and that's the problem. For documents that live and change — manuals, guides, course notes, anything with a version two — re-editability matters more than double-click. And a PDF is exactly as hard to reopen as an EPUB is to open.
The wrong surface
So why hasn't anyone just... written an EPUB?
Try to learn digital book production and see what happens. Within an hour you're wrestling with manifest entries, spine order, and unclosed tags in XHTML. That's the wrong surface: it's the format's plumbing, not the author's document. No writer creates a blog post by hand-editing HTTP headers.
Coming at it from the desktop-publishing end is no better. Reflowable EPUB is built around accessible structure, and retrofitting structure onto a page-layout mental model is a fool's errand from the other direction — you end up fighting the tool to un-design the page you just designed. The freedom to place anything anywhere is precisely the freedom to destroy structure.
Authors need a surface made of their materials: text, structure, media. Not zip internals, and not pasteboards.
Where the knowledge lives
There's a reliable diagnostic for a missing tool: ask where the working knowledge lives.
For ebook production it lives in decade-old forum threads, defended by the people who paid dearly to acquire The Knowledge. Newcomers proposing (or even seeking) simpler paths get told to learn the hard way. That's not a community failing — it's the natural ecology of a format without an authoring tool. The knowledge can't move into tools, so it calcifies into folklore, and folklore defends itself.
Compare the web. Nobody gatekeeps how to make a website anymore. The tools ate that knowledge — validators, frameworks, hosting platforms, browser devtools — and the folklore evaporated because it had somewhere better to live.
What the right surface looks like
If the description above of the problem resonates with your experience (as it does mine), the requirements write themselves.
Plain text files the author owns — files you can read anywhere, back up anywhere, and compare against last month's draft. Structure-first, not page-first. The EPUB as the living document — opened, edited, and repackaged with nothing mangled on the way through — not an export you'd dread reopening. Accessibility as the default output, not a repair job bolted on before delivery.
This is why plain text with light markup isn't a compromise — it's the mechanism. A markdown-like syntax can say "this is a heading, this is a list, this is emphasis" and almost nothing else, and that poverty is the point: every mark the writer can make is a piece of structure a reading system can reflow, scale, restyle, or read aloud. There's no way to fake a heading by making a line big and bold, so there's nothing to remediate later. The word processor needs an accessibility checker because its surface lets you write documents that only look structured; the constrained syntax needs none, because the unstructured document is unwritable.
To be fair about what's guaranteed: the constraint delivers the skeleton, not the complete, accessible body. Alt text for images, table semantics, the document's language — those still need the author's attention. But they arrive as a short, visible list, not an audit of everything.
And it has to run where the writer already is — which in 2026 means the browser. No installation, no OS gate, no license key: the same tool on the desktop, the tablet, and the borrowed laptop.
That's the whole prescription. Structure plain text into EPUB, re-editable, anywhere.
Coda
This isn't hypothetical. I've been building one attempt: SEED.html, a small browser-based editor where plain text goes in, an accessible EPUB comes out, and the same book opens back up for the next edit.
I recently watched someone write with it on an iPad with a bluetooth keyboard, and nothing about it was remarkable — which is the remarkable part. I use it comfortably on an Android tablet with a split keyboard - a great travelling/writing setup. That's the universality requirement, lived: not a feature, just the absence of a wall where every other workflow puts one.
It's one answer, not the answer. The point of the essay is the shape of the problem: a genuinely good format, served only by tools that were already busy being something else before EPUB 3 came along, and an authoring culture that never got the chance to exist. Somebody should build it several more times.
The memory theorist Aleida Assmann distinguishes storage memory (Speichergedächtnis) — preserved but inert, held in latency for future reference — from working memory (Funktionsgedächtnis) — inhabited, kept in active use. A WARC is storage memory by design: it fixes a page at a moment precisely so it can go dormant safely. A living EPUB is working memory: the document stays in circulation, and its value is that it never has to die to be preserved. Crucially, Assmann argues the two modes need each other rather than compete — which is exactly the relationship claimed here. See Erinnerungsräume (1999; English: Cultural Memory and Western Civilization, 2011).↩︎
This gap is conspicuous because the hard part is already done. Every major browser ships a PDF viewer, and PDF.js proved a decade ago that an entire document format can be rendered in the browser with no plugin. EPUB is a far easier target — it's zip, XHTML, and CSS, the very things a browser renders natively — and open-source web readers like Bene already do it. What's missing isn't technology; it's a browser vendor deciding that .epub deserves what .pdf got.↩︎
