How to make an ePUB for Kindle (and every other store)

To make an ePUB for Kindle, build a clean, reflowable ePUB 3 with a linked table of contents and tidy metadata, validate it against EPUBCheck, then upload that same file to Amazon KDP. KDP accepts ePUB and converts it to its own Kindle format on upload — so a single well-made ePUB serves Kindle, Kobo and Apple Books alike.

Does Kindle even accept ePUB?

Yes. This trips up a lot of authors who remember the old days of MOBI and AZW files. You no longer need to make a Kindle-specific file by hand. Amazon KDP accepts a standard ePUB upload and converts it on their end to the format Kindle devices and apps use. You hand over an ePUB; Amazon does the translation.

What this means in practice is liberating: you stop maintaining a separate Kindle file and a separate everybody-else file. You make one correct ePUB and it goes everywhere. Amazon does still publish its own desktop tool (Kindle Create) and historically offered converters like KindleGen, and their accepted-format list shifts over time — so before you upload, it is always worth a glance at KDP’s current help pages to confirm nothing has changed. Describe the file, then trust the official source for the exact spec of the day.

What is a reflowable ePUB 3, exactly?

An ePUB is not a PDF and it is not a Word file with a new extension. It is a small, self-contained website for your book — structured HTML and CSS, zipped into one package that every reading app knows how to open. Reflowable means the text rearranges itself to fit whatever the reader chooses: their font, their type size, their screen, light mode or dark. The book stays whole while the page redraws around it. That flexibility is the entire reason eBooks exist.

Most books — novels, memoir, business, self-help, anything text-led — want reflowable. The exception is heavily designed, image-led titles (picture books, many cookbooks) that need every element pinned in place; those use a different build called fixed-layout. If you are weighing the two, our companion piece on reflowable versus fixed-layout ePUB walks through which suits your book.

What does a clean ePUB actually need?

Most of the work that matters is invisible — it lives in the structure underneath, which is precisely the part a reader never sees and a validator always does. A sound reflowable ePUB has:

• A linked table of contents. Not a typed list of page numbers — a real, navigable TOC that jumps to each chapter. ePUB 3 carries this as a navigation document, and stores rely on it for the in-reader chapter menu.
• Clean metadata. Title, author, language and identifier, recorded correctly inside the file. This is what makes your book findable and shelvable in a store, and a wrong language tag alone can throw hyphenation and reading order.
• Semantic structure. Headings marked as headings, chapters as proper sections, paragraphs as paragraphs — so reflow, navigation and accessibility all behave.
• Disciplined styling. Relative units and restrained CSS, so text scales with the reader’s choices instead of fighting them.
• Sensibly handled images. Properly sized and referenced, with alt text where it matters, so the file stays small and opens fast.

Get these right and the book reads beautifully at any font size on any device. Get them wrong and it looks broken on half the apps and gets rejected by the other half.

What is EPUBCheck, and why does it decide everything?

EPUBCheck is the open, industry-standard validator for the ePUB format — and crucially, it is the same gate the stores themselves run your file through before it goes live. Think of it as the spell-check for your book’s underlying code: it reads the package and reports every place the file departs from the specification.

The honest trap here is that your own phone is forgiving and the validator is not. You test the file on your device, it looks fine, you relax — then it fails the store’s automated check, because reading apps quietly paper over errors that EPUBCheck flags in cold detail. The fix is to clear EPUBCheck before upload, not to discover the problems on launch day. A file that passes EPUBCheck uploads to Kindle, Kobo, Apple Books, Nook and Google Play without the parade of error codes.

Why does an ePUB get rejected?

When a store bounces a file, the cause is almost always structural rather than mysterious. The usual suspects:

• Invalid markup — malformed HTML or broken XML the validator refuses.
• A missing or unlinked table of contents, so the book has no navigation.
• Broken internal links or missing files referenced but not included in the package.
• Bad or incomplete metadata — no unique identifier, wrong or missing language.
• Images that are missing, mis-referenced or far too large.
• Leftover formatting junk from a word processor that bloats the file and breaks reflow.

Notice how many of these come from one place: exporting straight out of a word processor.

Can you convert a Word file to ePUB?

You can, and sometimes it even passes. Word and similar tools will export something they call an ePUB. The problem is that they drag along a mess of invisible formatting — stray styles, tracked-changes residue, odd character codes — that bloats the file, breaks reflow and trips EPUBCheck in ways that are genuinely maddening to diagnose. You end up debugging XML the night before launch instead of telling readers your book is out.

A clean conversion is less about the export button and more about the cleanup: stripping the manuscript back to honest structure, then rebuilding it as proper ePUB 3. The tools are free; the expertise is the part that turns “stuck for a week” into “live in an hour.” If you already have an ePUB that keeps getting rejected, it can often be repaired rather than rebuilt — though sometimes a rebuild is faster than the forensics.

Why does one validated ePUB matter across every store?

Because the alternative is maintaining a different file for every shopfront and re-fighting the same battles each time. A single validated, reflowable ePUB 3 is the master copy: Kindle takes it and converts, Kobo and Apple Books and the rest take it directly. One file, one validation pass, one upload routine per store — and a book that behaves the same wherever a reader meets it. If you are still deciding which storefront to lead with, our note on KDP versus IngramSpark is a useful next read.

At Librum we build every eBook as an EPUBCheck-validated reflowable ePUB 3 — linked TOC, clean metadata, tested across devices — with a Kindle-compatible export on request and a store-upload checklist, so launch day is about readers rather than error codes. If you would rather hand the structure to someone who does it daily, our ePUB production service is where to start.