By Meside AI · Last updated: 2026-08-06
Almost every "best EPUB translator" list is the same five products with invented star ratings. None of them tell you the thing that decides the outcome: a book is not a document, and most tools that translate text beautifully cannot put a book back together afterwards.
We run EPUB translations for a living. This post is the five criteria that actually separate tools that work at book length from tools that do not, each one grounded in numbers from our own pipeline, followed by an honest read of the common options — including the cases where the answer is not us.
Every completed translation in our system: 13 distinct full-length books (over 200,000 characters each, across 17 completed translation runs), 26,026 first-pass model calls, and the repair traffic those calls generated, logged February to August 2026. Measurements are on text with HTML markup stripped.
We are not naming the books — they are user-uploaded files. The one reproducible file in the set is Project Gutenberg #43936, The Wonderful Wizard of Oz, which is public domain: 233,240 characters, 1,948 translatable fragments.
An EPUB is a ZIP archive of XHTML files. Translation happens fragment by fragment — a paragraph, a heading, a caption, a table cell, a footnote — and the fragment is the unit of work, not the word.
Across those 13 books, fragment counts run from 1,378 to 11,286, spread across 8 to 160 separate XHTML files. Crucially, fragment count does not track length. Per 1,000 characters of text, books in our set range from 2.7 to 12.4 fragments — a 4.6× spread driven purely by structure. A book of long uninterrupted prose paragraphs behaves nothing like a book full of bulleted lists, pull quotes, sidebars and inline footnotes, even at identical word counts.
What to check: does the tool tell you how many pieces your specific book splits into, or does it quote you from the word count on the back cover? The second one has not opened your file.
This is the criterion almost nobody tests for, and it is the one that produces broken books.
When a model translates a fragment of XHTML, it can quietly drop a tag, mangle an entity, reorder emphasis, or return the fragment in the wrong language. Our pipeline validates every translated fragment against its source — same tags, same count, same order — and re-requests the ones that fail.
Against 26,026 first-pass fragment calls, 679 calls exist purely to repair fragments that came back structurally wrong: 619 in the first repair round, 60 in a second round for fragments that failed twice. That is a 2.6% first-pass structural failure rate.
That number sounds small until you multiply it by book scale. On a 6,000-fragment book, roughly 150 fragments come back with markup that does not match the source. A tool that does not check will happily hand you all 150 of them, and you will find them one at a time, in a reader, weeks later.
What to check: ask what happens to a fragment that comes back malformed. "The model is very accurate" is not an answer to that question.
Whatever a tool's per-call failure rate is, book length multiplies it. Our 13 hard call failures across 26,026 attempts is a low rate, but a single large book is over 11,000 calls — enough attempts that something will eventually time out, rate-limit, or drop.
The question is what that costs you. Restarting a book from fragment zero means paying again for the 6,000 fragments that already succeeded, and waiting again.
What to check: if the job dies at 60%, does it resume from 60%?
Replacing every text node in a ZIP archive of 8 to 160 XHTML files leaves a lot to get wrong that has nothing to do with translation: internal IDs, cross-chapter anchors, footnote back-links, the table of contents, the spine order, images and their captions.
A file that "translated successfully" but opens to a blank table of contents, or whose footnotes all jump to chapter one, has failed at the part that actually mattered.
What to check: open the result in a real reader before you judge the prose. Jump to the last chapter. Click a footnote. Check an image caption.
Output length is a property of the language pair, and it is bigger than most people expect. Measured across 44,543 fragments, English translated into Chinese comes back at about 0.35× the source character count — a book roughly a third the length. European targets in our set land near or above parity.
That has real consequences for bilingual output, for reader progress estimates, and for anyone judging completeness by file size. We wrote it up with the full per-book figures in translate EPUB to Chinese.
What to check: if a tool's output is a third the size and it cannot tell you why, you cannot distinguish a correct Chinese translation from a truncated one.
Free, fast, and supports more languages than anything else. It translates text well enough for comprehension.
It is not an EPUB pipeline. There is no format preservation, no fragment-level repair, no resume, no reassembly — you are unzipping the archive, feeding files through by hand, and putting it back together yourself. For a chapter or a page, this is genuinely the right tool. For a book, criteria 1 through 4 are all on you.
Consistently strong translation quality, particularly on European language pairs, with glossary support and a solid API.
Same structural gap: it translates text, not books. If you use it for an EPUB you are writing the segmentation, validation and reassembly yourself — which is a real option if you are comfortable with a script, and DeepL is a good engine to build that on.
A mature browser extension with a large user base, bilingual EPUB output, and support for bringing your own model. If your main need is reading foreign-language content in the browser and occasionally exporting a bilingual EPUB, this is a sensible place to start, and we would rather say so than pretend otherwise. Its centre of gravity is reader-side translation rather than one-pass whole-book conversion.
Also a real option, and worth being straight about: if you have one short book, an API key, and an afternoon, you can get there. What eats the afternoon is not the prompt. It is resume, structural validation, and keeping the EPUB's internal links pointing at the right places after every text node has been replaced.
We put the full engineering account in why building an EPUB translator is harder than you think, partly so people can decide against building it with their eyes open.
Stated plainly so you can discount it accordingly: this is our product, and the measurements above come from its pipeline.
Pricing: Pay-per-use — $0.005 per 1,000 characters, $1.99 minimum per book, computed from the file you upload and shown before anything runs.
What it is built around: the five criteria above. Fragment-level segmentation, per-fragment structural validation with dedicated repair rounds, resume, EPUB reassembly and validation, 16 target languages including Simplified and Traditional Chinese as separate choices, and optional bilingual output.
Where it is not the answer: browser-side reading of web pages, single chapters or short documents, and anything with DRM — we detect DRM and stop, we do not remove it.
You do not have to take a list's word for it, ours included. Download the public-domain Wizard of Oz EPUB and run it through whatever you are evaluating. Then:
Whatever you find, that six-step pass tells you more than any star rating, because it tests the parts that actually break.
If you are reading in a browser, use a reader-side extension. If you have one short book and enjoy scripting, write the script. If you need a whole book converted in one pass, with the file still a valid EPUB at the end, that is the case we built EPUB Translator for — see the exact price for your file before anything runs.
The honest summary is that the translation step is the easy part in 2026, and every tool above does it competently. What separates them is everything that happens around it.