Get in Touch

What Kindle Book Formatting Actually Covers

Kindle book formatting is the discipline of producing an EPUB3 source file that survives KDP’s conversion workflow and renders as a clean KFX on every current Kindle device and app. It is a narrower problem than generic ebook formatting. EPUB3 for Apple Books, Kobo, and Google Play assumes the storefront ships your file as-is; Kindle does not. KDP ingests your EPUB3 (or DOCX, or a KPF exported from Kindle Create) and re-encodes it into Amazon’s proprietary container before any reader sees a page.

That conversion step is where Kindle-specific quirks live: the KFX format introduced in 2015, Bookerly as the default typeface on E Ink hardware, and Kindle Previewer 3 as the only validator whose verdict matches what KDP will actually do to your file. A book that passes EPUBCheck cleanly can still arrive on a Paperwhite with collapsed drop caps, substituted fonts, or a navigation document that no longer matches the printed table of contents. The work below is what separates the two outcomes.

KFX, KF8, AZW3: what each device actually reads

• KFX — the modern format introduced in 2015. Served to all current Kindle devices and Kindle apps on iOS, Android, Mac, and Windows. Supports enhanced typography, improved page rendering, and Amazon’s Bookerly hinting.
• KF8 (AZW3) — the format Kindles served from 2011 to 2015. Still accepts CSS, but a narrower subset than EPUB3, and KDP only generates it as a fallback for older hardware.
• MOBI — the legacy format, retired for new KDP uploads in August 2022. Pre-2014 Kindles may still receive a MOBI fallback when one is available.

Authors upload EPUB3, DOCX, or KPF to KDP. KDP converts that source into KFX for new devices, KF8 for the 2011–2015 generation, and a MOBI fallback where one is needed. The formatter’s task is to deliver a source file that converts cleanly into all three without visible regressions.

What Kindle’s converter strips or alters

• Drop caps — the float-left CSS pattern that works in Apple Books often collapses to a plain capital letter on older Kindle hardware. Use the span class approach Amazon documents in the Kindle Publishing Guidelines.
• Custom fonts — KDP permits embedded fonts in EPUB3 uploads, but Paperwhite and Oasis frequently substitute the reader’s chosen system font (Bookerly, Amazon Ember, Helvetica) regardless.
• Complex CSS — transforms, animations, fixed positioning, and viewport units are silently dropped during conversion.
• Page-break-after on inline elements — ignored. Apply page-break-before to the heading’s block-level container instead.
• Embedded JavaScript — rejected outright at the OPF validation step.

Kindle Previewer 3 warnings, ranked by severity

Every Kindle file should pass through Kindle Previewer 3 before it reaches KDP. The tool produces four categories of message, and they are not equally urgent:

• Blockers — broken navigation document, missing OPF manifest entries, unsupported image formats. These prevent KDP from generating a valid KFX and must be resolved before upload.
• Image-DPI warnings — flagged when raster images fall below 300 DPI at their displayed size. Cosmetic, but visible on Paperwhite and Scribe screens.
• Font-substitution warnings — usually safe to ignore. Bookerly is a competent fallback for body text, and most readers override embedded fonts anyway.
• Navigation mismatch — the printed table of contents does not match the nav doc or NCX. Resolve this; without a valid nav doc readers cannot jump between chapters using the Kindle menu.

Why Authors Choose Kindle-Specific Formatting

• One format, every Kindle device — the same source renders correctly on Paperwhite, Oasis, Scribe, Fire tablets, and the Kindle apps without per-device tuning.
• Previewer-clean output — files arrive at KDP with no blocker warnings, so the title goes live within Amazon’s standard 72-hour review window.
• Working navigation — the nav doc, printed ToC, and chapter starts agree, so the Kindle menu jumps to the right place every time.
• Drop caps that survive conversion — first-paragraph styling renders on KFX devices instead of collapsing to plain capitals on the older fleet.
• Predictable typography — line height, paragraph indent, and chapter spacing match Bookerly’s metrics rather than fighting them.

Kindle formatting branches by content type. Image-heavy titles (children’s, photo books, cookbooks) need fixed-layout EPUB rather than reflowable. The KDP upload step handles validation. Authors who want a print companion need KDP paperback formatting; professional typesetting sits underneath the print interior. Specialty categories like cookbooks have their own composition rules.

Frequently Asked Questions About Kindle Book Formatting

Do I upload EPUB3 or MOBI to KDP in 2026?
EPUB3. Amazon retired MOBI uploads in August 2022. KDP also accepts DOCX and KPF files exported from Kindle Create, but EPUB3 gives the formatter the most control over how the final KFX renders.

Will my embedded font actually display on a Paperwhite?
Sometimes. KDP permits embedded fonts in the EPUB3 manifest, and they survive the KFX conversion. However, Kindle E Ink devices give the reader a font picker that overrides embedded choices, and Bookerly is the default for most users. Embed fonts for headings and display use; assume body text will render in Bookerly.

What is the difference between Kindle Previewer 3 and EPUBCheck?
EPUBCheck validates against the EPUB3 specification. Kindle Previewer 3 simulates KDP’s actual conversion to KFX and KF8, then renders the result on emulated Kindle devices. A file can pass EPUBCheck and still produce broken pages on a Paperwhite, which is why Previewer 3 is the relevant validator for Kindle.

Does Kindle generate the table of contents automatically?
Kindle reads the nav doc declared in the EPUB3 OPF and uses it for the menu-driven Go To panel. A separate printed ToC inside the manuscript serves the reader who flips to the front of the book. Both should exist, both should match, and the nav doc must use the EPUB3 nav element rather than a legacy NCX alone.

Can I use the same EPUB3 file on Kindle, Apple Books, and Kobo?
The same source file can be uploaded to all three, but it will not render identically. Apple Books and Kobo serve the EPUB3 directly and respect more CSS. Kindle re-encodes to KFX and strips a documented subset. A file engineered for Kindle stays inside that subset deliberately, which is why a single-source EPUB3 often looks plainer on Kindle than the same file does on Apple Books.