How Many Tokens Is a Book? Data From 9 Real EPUBs

If you have ever thought about translating a whole book with an LLM yourself, the first question is deceptively simple: how big is a book, really?

Most estimates start from the word count on the back cover and stop there. That number turns out to be the least useful of the three that matter. We run EPUB translations for a living, so we went back through our own pipeline and measured what a book actually costs in tokens, in fragments, and in model calls.

This post is the raw numbers. No tool is going to look good or bad because of them — they are properties of books, not of software.

What we measured

The dataset is every completed EPUB in our system larger than 100,000 characters — nine books — plus 26,578 model calls logged between February and August 2026.

The books are a mix: O'Reilly-style technical references, business non-fiction, a science-fiction novel, and one public-domain classic. We are not naming most of them, because they are user files. The one we can name is The Wonderful Wizard of Oz (L. Frank Baum, 1900), which is public domain and free to download — so you can reproduce every number in this post against the same file we used.

Answer 1: a book is 200,000 to 1.6 million characters

Here is the range across the nine books:

The largest book in the set — a fourth-edition technical reference — is 261,362 words and 677,582 input tokens.

Across every book where we have a real tokenizer count rather than an estimate, English prose lands at roughly 2.3 characters per token (observed range 1.91–2.56), or about 2.6 to 3.3 tokens per word depending on how technical the vocabulary is. Jargon-dense books tokenize worse: the infrastructure book hit 3.29 tokens per word, while a business book came in at 2.29.

A useful rule of thumb: a normal novel is a quarter-million input tokens; a fat technical book is closer to three quarters of a million.

Answer 2: output is bigger than input

This one catches people out when they budget.

Across 26,340 successful calls, we sent 16,635,992 input tokens and received 18,675,402 output tokens — a ratio of 1.12 output tokens for every input token.

Translation is not a summarization task. The translated text is a full-length replacement for the source, and most target languages need slightly more tokens to say the same thing than English does. If you price a job assuming output ≈ input, you will be about 12% light before you account for anything else. If you are translating into a language the tokenizer handles poorly, the gap is wider.

Answer 3: word count doesn't tell you how much work a book is

This is the number that surprised us, and it is the one we would most want to know before starting.

An EPUB is not a stream of text. It is a ZIP archive of XHTML files, and translation happens fragment by fragment — a paragraph, a heading, a caption, a table cell, a footnote. So the unit of work is not the word. It is the fragment.

Fragment counts do not track length:

Look at the first and last rows. The startup book is 2.5× longer than the business book but splits into half as many fragments. Per unit of text, one book is 4.6× more fragmented than the other.

Why? Structure. A book full of bulleted lists, pull quotes, sidebars, tables, and inline footnotes shatters into short fragments averaging 81 characters. A book of long uninterrupted prose paragraphs averages 373. Same words, very different job.

This has real consequences if you are writing the script yourself:

• Short fragments waste context. An 81-character fragment sent alone gives the model almost nothing to disambiguate pronouns, gendered adjectives, or terminology against. Quality drops in exactly the books that are hardest to translate well.
• Fragment count sets your call count, not word count. Batch aggressively and you lose structural fidelity; don't batch and you make thousands of calls.
• You cannot predict either from the blurb. You have to open the file and count.

Answer 4: at book scale, rare failures stop being rare

Our main translation path logged 24,733 calls. Whatever your per-call failure rate is, multiply it by a number in the thousands, because that is how many calls one book takes.

Failures are also not the only retry path. Our pipeline runs dedicated repair rounds after the main translation pass — 1,229 calls in this dataset exist purely to fix fragments that came back structurally wrong the first time: a dropped tag, a mangled entity, a fragment that came back in the wrong language. That is a normal cost of doing this at length, not an anomaly.

If you are building this yourself, the thing that will actually eat your weekend is not the prompt. It is:

• resuming a run that died at fragment 6,000 of 11,286 without re-paying for the first 6,000
• detecting that a fragment came back with broken markup and re-requesting just that one
• keeping the EPUB's internal IDs, anchors, and footnote links pointing at the right places after every fragment has been replaced
• validating that the result still opens in a reader

So should you just do it yourself?

Honestly: sometimes yes. If you have one short book, a tolerance for cleanup, and an afternoon, a script plus an API key will get you there. That is a real option and we would rather tell you than pretend otherwise.

There are also good general-purpose tools in this space. Immersive Translate, for example, is a mature browser extension with a large user base that supports bilingual EPUB output and lets you bring your own model — DeepSeek, OpenAI, Claude, Gemini, or DeepL. If your main need is reading foreign-language content in the browser, that is a sensible place to start.

What the numbers above argue is narrower and, we think, harder to dispute: the difficulty of book translation is concentrated in structure and scale, not in the translation step itself. A model that translates one paragraph beautifully tells you very little about what happens across 11,286 of them, with the file still needing to be a valid EPUB at the end.

That is the part we built EPUB Translator around — segmentation, per-fragment retry, structural repair, and validation. We wrote up the reasoning in more detail in why a dedicated tool beats a raw LLM, and the mechanics in how it works.

Reproducing this

Download Project Gutenberg #43936 and you have the exact file behind the Oz column: 233,240 characters, 43,194 words, 1,948 translatable fragments, averaging 120 characters each.

Unzip it, walk the XHTML files, and count the text nodes. Whatever tool you end up using — ours, someone else's, or your own script — that count is the number that determines the size of the job.