An EPUB is a zip of web pages plus a running order. The running order is the part converters get wrong, because it is stored in a manifest rather than implied by the filenames. Get that right, carry the images across, and the rest is a layout decision you make rather than something the book dictates.
What is actually in the file
Rename any EPUB to .zip and open it and you will find a small website. Each chapter is an XHTML file, the styling is CSS, the images sit in a folder, and one package file ties it together. That package file is the important one. It holds two lists: a manifest of everything in the book, and a spine, which is the order a reader should move through it.
META-INF/container.xml
A pointer. Its only job is to say where the package file lives, because publishers put it in different places.
The package file
Title, author, the manifest of files, and the spine that gives the reading order.
The chapters
Ordinary XHTML. Headings, paragraphs, lists, images, tables, the same structures a web page uses.
The navigation document
The table of contents a reader app shows. Useful, but it is the spine that decides the order.
Why chapters come out shuffled
Files in a zip are not stored in any meaningful order, and the names are whatever the production tool chose. A converter that reads the zip and processes what it finds gets alphabetical order, which is where the classic failures come from: chapter 10 lands directly after chapter 1 because "10" sorts before "2", front matter ends up in the middle, and an appendix opens the book.
The fix is not clever sorting. The order is written down in the spine, and the only correct thing to do is read it. This tool does, and it lists the chapters it found in that order before you convert, so a wrong order is visible before you have a PDF rather than after.
Convert a book you know, and look at whether the output starts where the book starts. If the front matter or an appendix has drifted, the tool sorted filenames, and every book you put through it will have the same fault.
The page count question
People ask how many pages their EPUB will be, and the honest answer is that the question has no answer until you decide. EPUB is reflowable by design. The text rearranges itself for the screen it is on, which is why an ereader shows a different page count when you change the font size, and why ebooks tend to quote reading time rather than pages.
PDF is the opposite. A PDF page is a fixed rectangle with fixed contents. So converting means choosing a paper size and a text size, and those two choices decide the length. The same novel at Compact on A4 and at Large on US Letter can differ by half again in page count. Neither is more correct.
DRM, and why a purchased book will not convert
Most ebooks bought from a major store carry DRM. The zip structure is still there, but the chapter files inside are encrypted, and an extra file records that fact. Without the key, which lives with the retailer and the account that bought the book, there is nothing to read.
What a converter does at that point is the difference between an honest tool and a bad one. The encrypted bytes are still data, so a tool that does not check will happily run them through its parser and hand back a PDF of garbage characters, or an empty document, with no explanation. This tool looks for the encryption record first and stops with a clear message.
Books that are not encrypted, and which convert normally, include anything from Project Gutenberg or Standard Ebooks, most direct sales from technical publishers, review copies, files exported from writing software, and anything you made yourself.
What survives the conversion, and what does not
Comes across
Reading order from the spine, headings and their hierarchy, paragraphs, bold and italic, ordered and unordered lists, blockquotes, tables, images from inside the book, the title and author as PDF metadata, and a bookmark tree built from the book's own headings so the PDF opens with working navigation.
Does not
The book's own stylesheet, embedded fonts, fixed-layout page design, interactive or scripted content, and audio or video.
That trade is fine for a novel or a non-fiction book, where the structure carries essentially all the meaning. It is a poor trade for a heavily designed book, a cookbook, a children's picture book or anything published as fixed-layout EPUB, where the design is the point. For those, converting to PDF will lose what you were trying to keep.
Questions people actually ask
What people ask when a book has to become a document.
01My PDF came out enormous. Why?
Usually a book with many images, which are carried across at their original resolution. Run the result through Compress PDF, which will bring the images down without touching the text.
02Can I go the other way, PDF to EPUB?
Not here. It is a genuinely harder problem, because a PDF has fixed pages and recovering a sensible reflowable structure from them means guessing at what was a heading, what was a column and what was a running header. PDF to Markdown is the closest thing on this site and a reasonable starting point.
03Why is the text not in the book's font?
The renderer uses its own embedded fonts rather than applying the book's stylesheet. For most books this is unnoticeable. If the typeface specifically matters, an ereader that exports to PDF will do better.
04Does it handle .azw3 or .mobi from Kindle?
No. Those are different formats, not EPUB with another extension, and Kindle files are usually DRM-protected as well. Convert to EPUB first with something like Calibre, then bring the EPUB here.
05Will the PDF be searchable?
Yes. The text is laid out as real text with real fonts, not as an image of text, so search, copy and select all work normally.