I printed a technical book for a long flight once and ended up with 940 pages, because I accepted whatever the converter offered and it offered A4 at 11 point with narrow margins. The same book at A5 and 14 point was 612 pages that read like a paperback. Nothing about the text changed. What changed was that a reflowable file does not have a page count until something decides where the pages fall, and the thing deciding was a default I had not looked at. That is the whole job of an EPUB to PDF conversion, and knowing it is a typesetting decision rather than a file copy tells you what to expect from the result.
TL;DR: EPUB is reflowable, which means the book has no pages of its own and the reading app chooses where lines and pages break based on your screen and font size. PDF is the opposite: every page is already drawn. So converting is typesetting, not copying, and the output is a new layout rather than a reproduction of one. Text, headings and chapter order survive. The publisher's fonts, exact line breaks, images and clickable table of contents do not. The EPUB to PDF converter on toolz.dev does the work in your browser, so the book is never uploaded, and it offers plain text as well, which is the better output when you want to search or quote rather than read.
Why does an EPUB have no pages?
Because it was designed not to have any, and that was the right decision for reading on screens.
An EPUB chapter is XHTML. It carries structure, which is to say headings, paragraphs, lists and emphasis, and almost no geometry. The reading system supplies the geometry at the moment you open it: your screen width, the font you chose, the size you set, whether you are holding the phone upright. Change the size and the book repaginates. This is why a page number in an ebook is unstable and why ereaders quote a percentage or a location instead.
PDF holds the opposite contract. Every page is a fixed canvas with text placed at coordinates on it, which is why a PDF looks the same everywhere and why reading one on a phone means pinching and scrolling sideways.
Neither is better. They answer different questions. The confusion arises because both are "a book in a file", so converting between them sounds like changing a wrapper, when it is closer to typesetting a manuscript. There is one exception worth knowing: EPUB also supports a fixed-layout mode, used for cookbooks, children's books and comics where the design is the content. Those convert to PDF much more faithfully, because the geometry was already decided.
What is inside an .epub file?
A ZIP of web pages, with one detail at the front that makes the format identifiable without unzipping anything.
The EPUB 3.3 specification requires the mimetype file to be the first file in the archive, and requires that creators "MUST NOT compress or encrypt" it. Its contents are the fixed string application/epub+zip. Because it is stored uncompressed at a known offset, you can read it straight out of the raw bytes:
# the first 60 bytes of any valid EPUB
head -c 60 book.epub
# PK..........mimetypeapplication/epub+zip...
# and it is a ZIP, so you can look inside without any ebook software
unzip -l book.epub | head
After that the structure is fixed by the spec rather than by convention, which is what makes a converter possible at all:
META-INF/container.xmlsits at a known path and names the package document. It is the only location in the format you can rely on, which is why every reader starts there.- The package document, usually
content.opf, lists every resource in the book with an id and a media type, then gives the spine: the ordered list of documents that is the default reading order. - The chapters are XHTML files referenced from that manifest, in whatever directory layout the publishing tool happened to produce.
So the conversion is: unzip, read the container, read the spine, pull headings and paragraphs out of each chapter in that order, typeset. Nothing in that sequence needs a server, which is why it can run in a browser tab.
What survives the conversion, and what does not?
Be clear about this before you convert a book you care about, because the honest answer is "the words and the structure, not the design".
| Survives | Does not survive |
|---|---|
| Chapter order, from the spine | The publisher's fonts and typography |
| Headings, at three levels | Exact line and page breaks |
| Paragraphs, lists, blockquotes | Embedded images and figures |
| The text itself, entities decoded | Footnote links and cross-references |
| Your page size and body size | A clickable table of contents |
The dropped column is not laziness, it is the nature of the job. Reproducing a reflowable book's styling as fixed pages faithfully means implementing a CSS layout engine and embedding the publisher's licensed fonts, which is a typesetting product rather than a converter. If what you want is the designed edition, look for the publisher's own PDF. If what you want is the words, in order, on pages you can print, annotate or send to a tablet, the conversion gives you exactly that.
One side effect of using the PDF standard fonts rather than embedding the book's own: the output carries no font data at all, so a 400-page novel lands around a megabyte. A PDF with embedded fonts for the same text is routinely five times that. That is also why running the result through a PDF compressor saves almost nothing: there is no image data and no font data to squeeze, only text.
Which page size and body size should you pick?
Pick for the destination, and remember that the two settings interact more strongly than either looks.
A point is 1/72 of an inch, so A4 is 595 x 842 points, US Letter is 612 x 792, and A5 is 420 x 595. The default margin of 56 points is just under 20 millimetres, which is the conventional book margin rather than the conventional document margin.
Three combinations cover almost everything:
A4 at 10 or 11 point is the printing-to-save-paper setting. The line is long, around 90 characters, which is past what typographers consider comfortable, but you get the fewest pages. Use it for reference material you will skim and annotate rather than read front to back.
A5 at 13 or 14 point is the reading setting, and the one I would default to. The measure lands near 65 characters, which is where sustained reading is comfortable, and the result looks like a paperback. It produces more pages and they are smaller pages.
US Letter at 12 point is the right answer when somebody else in North America is printing it, for no reason other than that their printer is loaded with that paper.
Headings scale from the body size rather than being set independently, at 1.7x for level one, 1.4x for level two and 1.2x for level three, so raising the body size raises everything proportionally and the hierarchy holds.
Why does a heading sometimes jump to the next page?
Because it was about to become the last line on a page, and a heading separated from the text it introduces is the one pagination fault every reader notices immediately.
The rule in the paginator is to keep a heading with at least one line of what follows it. When a heading plus one body line would not fit in the remaining space, the page is flushed early and the heading starts the next one. That is why a converted PDF sometimes has a page ending two lines short.
Typographers call the general problem widows and orphans, and professional typesetting goes further, pulling lines back and forth between pages to avoid a single line of a paragraph stranded on its own. This converter handles the heading case and not the general one, which is a deliberate limit: a full widow and orphan pass needs to reflow backwards across pages, and the heading rule catches the fault readers complain about.
Should you convert to plain text instead?
For a surprising number of jobs, yes, and it is both faster and more useful.
Plain text wins whenever the book is going to be read by something other than a person. Searching a whole book with grep. Feeding chapters to a script. Pulling quotes without fighting a PDF's column order. Counting words. Reading in an editor on a machine with no PDF viewer. None of those want page furniture, and a .txt file is chapters in order, separated by blank lines, and nothing else.
It is also the fastest output, because no layout work happens at all. The structure is read, the blocks are flattened, the file is written.
What you give up is everything a page gives you: headings that look like headings, a printable artefact, stable references to point at. For reading, PDF. For working with the text, plain text. The same split applies in reverse when you have a PDF and want the words out of it, which is what PDF to text is for.
Why will my library book not convert?
Because it is encrypted, and no converter running in your browser can read it.
A book borrowed from a library or bought from most major stores carries DRM. The EPUB structure is still there, but the content documents are encrypted, with the keys tied to an account and an authorised application. The format has a place for this: META-INF/encryption.xml, which the spec defines as holding "information about the encryption of publication resources". A converter opening such a file finds chapters it cannot read, and fails.
This is not a bug to work around and I am not going to tell you how to. The practical routes are the legitimate ones: many publishers sell DRM-free EPUBs directly, Project Gutenberg and Standard Ebooks are DRM-free by policy, your library's app can usually send a book to a device without you converting anything, and a book you want on paper often exists as a PDF edition the publisher sells.
A file that is DRM-free converts normally, and most of what people need converting is DRM-free already: a manuscript, a technical book from a publisher that sells direct, documentation exported as EPUB, a public domain classic.
Why can't I convert a MOBI or an AZW3?
Because they are not ZIP archives of web pages, and the entire approach above depends on that.
MOBI, AZW, AZW3 and KFX are Amazon's own formats, built on a different lineage with a different internal structure. A browser can unzip a ZIP; it cannot open a PalmDOC-derived binary database without a dedicated parser for each generation of the format. So the tool names the format rather than failing with a confusing archive error.
The route that works is Calibre on your own machine: convert the AZW3 to EPUB there, then bring the EPUB here. That ordering is also better for the result, because Calibre knows about the metadata and structure in those files and produces a cleaner EPUB than any one-step conversion would.
Does the book leave my machine?
No. The unzipping, the parsing and the PDF writing all happen in the browser tab.
That matters more for books than people assume. An unpublished manuscript, a thesis under embargo, an internal handbook, a book you have a licence to read but not to redistribute: uploading any of those to a free conversion site means handing a complete copy to a company whose business model you have not read. Here no copy exists to hand over, which you can confirm in the devtools network panel while the conversion runs.
The practical limit is tab memory rather than a plan, and for EPUB that limit is generous, since a long novel is a few megabytes of compressed XHTML. Image-heavy fixed-layout books are the ones that get large, and those are also the ones a text-extracting converter serves least well.
What about the other direction, PDF to EPUB?
Much harder, and worth understanding why, because it explains what a PDF contains.
A PDF does not store paragraphs. It stores glyphs positioned on a page, grouped into text-showing operations that often break mid-word and do not have to appear in reading order. Reconstructing paragraphs means inferring them from coordinates: this run sits below that one with a consistent leading, this gap is a column break rather than a paragraph break, this repeated line near the bottom is a running footer rather than a sentence. Every PDF text extractor is doing that inference, and every one of them gets some of it wrong.
Converting a two-column academic paper is where it shows: naive extraction interleaves the columns, producing alternating half-sentences. That is not a bug in any one tool so much as the consequence of a format that records where ink goes and not what the ink means.
Going EPUB to PDF is the easy direction precisely because the structure is present in the source and the geometry is the thing being invented. Going back means inventing the structure from geometry, which is why the results are so much more variable. When all you need is the words, PDF to text is the honest tool, and for the layout-preserving jobs around a PDF there are compress and Word conversion rather than a round trip through EPUB. The PDF toolkit guide covers which of those applies to which problem.
How do you check the conversion came out right?
Four checks, each about ten seconds, and they catch nearly everything that goes wrong.
Count the chapters. The spine says how many documents the book has, and unzip -l book.epub lists them. If the PDF has visibly fewer chapter headings than the EPUB has content documents, something was skipped: usually a chapter that holds only an image, which a text extractor correctly reads as empty and a reader expecting a page finds missing.
Read the last page. Truncation at the end is the failure mode that hides best, because the first hundred pages look perfect. If the book ends mid-sentence, the spine was not fully walked.
Search for a word from the middle. Open the PDF, search for a phrase you know appears halfway through, and confirm it is there and in the right chapter. This catches reading-order problems, where front matter marked as skippable lands somewhere unexpected.
Look at the punctuation. EPUBs are full of character entities, and a converter that fails to decode them leaves — or ’ visible in the text. The converter here decodes both named and numeric entities, and maps typographic dashes to plain hyphens on purpose, so em dashes in the source come out as hyphens in the PDF rather than as boxes in a font that lacks the glyph.
If a book fails all four, it is usually DRM rather than a conversion fault, and the error will have said so at the point you selected the file.
