Ebook formatting for Kindle — an ePub that's clean from the start

• →Empty or copied-from-filename metadata
• →Generic auto-generated cover, not yours
• →Flat table of contents if the document didn't use heading styles
• →Validation warnings that Apple Books or KDP reject on review

An ePub isn't «a converted Word file»: it's a package with rules — a ZIP of XHTML documents, CSS stylesheets and a manifest (OPF) describing the book. Amazon KDP accepts that ePub directly (it converts it internally to its KFX format) and Apple Books uses it as-is, so one valid, standard ePub serves both stores. These are the rules that decide whether they accept it and whether it reads well on a Kindle, an iPad or a phone:

• →Reflowable, not fixed-layout. Text must flow and re-adapt to the screen size and the font size the reader picks. A «fixed-layout» ePub inherited from the PDF reads badly on a Kindle: clipped lines, no font control. For novels and non-fiction, reflowable is mandatory.
• →Dual navigable table of contents. The nav.xhtml (EPUB 3 standard) and the toc.ncx (compatibility with older Kindle readers) must exist and point to every chapter. Without them, the reader can't jump between chapters or use the device's table of contents.
• →Images inline, in RGB and under 5 MB. Amazon requires each image inserted inline with the text (not floating or absolutely positioned), in RGB colour —never CMYK, which is for print— and under 5 MB per image. A single out-of-spec image is enough for a rejection.
• →Complete metadata in the OPF. Title, author, language and ISBN actually declared, not inherited from the filename. They're what the store displays and uses to classify the book.
• →Error-free validation. The industry standard is EPUBCheck: it verifies the package meets the EPUB specification. If it doesn't validate, Apple rejects it on review and KDP may too.

They're essentially the same demands as the print interior you prepare — which is why the layout and the ePub share the same structure. If you're also publishing in paperback, start with the complete guide to formatting a book for Amazon KDP.

Calibre or Pandoc convert the Word file in seconds, but they carry over whatever the document didn't have solved. These are the failures that show up again and again — and that you almost never see until the store rejects the file:

The ePub isn't «converted» at the end as an afterthought: it's generated from the same structure already detected in your manuscript, and it goes through deterministic checks before you download it. Specifically:

• →Table of contents and NCX from your roles. The Part / Chapter / Section hierarchy detected when analysing the interior is reused to build the nav.xhtml and the toc.ncx: the same structural work, two outputs (print and ebook), without repeating it or asking you again.
• →EPUBCheck as a gate, not a decoration. Every ePub is validated with EPUBCheck before delivery; if any issue appears, you're warned with the concrete error next to the download button —with the number of failures— instead of silently handing you a file Amazon would reject. Nothing is «delivered blind».
• →Images normalised to KDP's spec. Before packaging, each image is converted to RGB if it came in CMYK and recompressed when it exceeds 5 MB, automatically and only when needed. No image in the manuscript brings down the review over colour or weight.
• →Endnotes linked correctly. Footnotes become endnotes with a round-trip back to the actual chapter where each reference appears, without JavaScript (which many readers block and EPUBCheck flags).
• →Genuinely reflowable. The ePub's CSS flows, with no «fixed-layout» leftovers from the PDF: the text re-adapts to the device and respects the font and size the reader chooses.

It's the same criterion used to validate the print interior against the printing rules: check with evidence before delivering, not after the rejection.