Publishing on Kindle is a format conversion problem. You create content in one format, upload it to KDP, and Amazon converts it to their internal delivery format (KFX) for Kindle devices and apps. The quality of that conversion depends entirely on what you upload. A clean EPUB produces a clean Kindle book. A messy DOCX produces formatting surprises. A PDF produces a "print replica" that's unreadable on small screens.

This guide covers the practical details: which format to upload, how to prepare your cover and interior images, what Amazon's conversion pipeline does to your content, and how to preview the final result before readers see it.

Accepted Upload Formats

KDP accepts four manuscript formats, each with different strengths:

EPUB: The Recommended Upload

Amazon shifted to recommending EPUB as the preferred upload format in 2023. EPUB's HTML/CSS content model translates directly to KFX's HTML-based rendering engine, producing the most predictable results. Your CSS styling, chapter structure, table of contents, embedded fonts, and images all transfer cleanly.

KDP runs epubcheck on uploaded EPUBs and rejects files with errors. Before uploading, validate locally: java -jar epubcheck.jar your-book.epub. Common blockers: unclosed HTML tags, missing required metadata (dc:title, dc:language, dc:identifier), and manifest items referencing non-existent files.

If you're starting from a DOCX manuscript, convert to EPUB first, then refine the EPUB in Sigil or Calibre's editor before uploading to KDP. This two-step process gives you control over the intermediate format.

DOCX: Convenient but Lossy

DOCX uploads work for simple manuscripts but introduce an additional conversion step. KDP converts DOCX to HTML to KFX — and the DOCX-to-HTML step interprets Word formatting heuristically. Issues that arise:

  • Paragraph spacing — Word's "space after paragraph" doesn't always translate to the expected CSS margin. Some books end up with double-spaced paragraphs or no paragraph breaks
  • Font overrides — Custom fonts in Word may not embed correctly. KDP may substitute default fonts
  • Headers/footers — Word headers and footers are ignored (ebook readers don't have headers/footers)
  • Text boxes and shapes — Dropped or rendered as images
  • Track changes and comments — Must be resolved before upload. Leftover tracked changes can appear in the published book

For simple prose (novel, memoir, essay collection), DOCX works fine. For anything with custom formatting, images, or complex layout, convert to EPUB first.

KPF: Kindle Create's Output

KPF (Kindle Package Format) is the output of Kindle Create, Amazon's free desktop formatting tool. KPF is a ZIP containing structured content optimized for the KDP pipeline. It's the most "Amazon-native" upload format.

Kindle Create imports DOCX or PDF and provides visual formatting tools: chapter theme selection (how chapter headings look), first-paragraph styling, drop cap settings, image placement, and table of contents generation. It exports KPF, which you upload directly to KDP.

Use KPF when: you want Kindle-specific formatting features (themed chapter pages, specific drop cap styles), you're creating a print replica from PDF, or you want to preview exactly how Amazon will render your content. Skip KPF when: you want platform-independent formatting (KPF only works on Amazon) or you need precise CSS control (Kindle Create's visual editor is limited).

PDF: Print Replica Only

Uploading a PDF to KDP creates a "print replica" Kindle book — fixed-layout pages that look exactly like the PDF. No text reflow, no font size adjustment, no dark mode. The pages are rendered as images on the Kindle, identical to the PDF layout.

Print replicas are appropriate for: textbooks with complex layouts, technical manuals with diagrams, cookbooks with designed pages, and content where the page design IS the product. They're inappropriate for novels, non-fiction prose, or any content that should be readable on a 6-inch e-reader screen — the text will be tiny and unzoomable line by line.

KDP pricing for print replicas follows the same royalty structure as reflowable ebooks, but file delivery costs are higher (Amazon charges a delivery fee per MB for 70% royalty books), so large PDF-based books eat into royalties significantly.

Cover Image Specifications

The cover is the single most important visual element for ebook sales. Amazon's specific requirements:

  • Minimum dimensions: 625 x 1000 pixels (width x height)
  • Recommended dimensions: 2560 x 1600 pixels — this is the ideal target
  • Maximum: 10,000 pixels on the longest side
  • Aspect ratio: 1.6:1 (height:width). A 2560x1600 cover is exactly 1.6:1
  • File format: JPEG or TIFF only. Amazon rejects PNG covers
  • Color space: RGB. CMYK covers are rejected (CMYK is for print; screens use RGB)
  • DPI: 300+ recommended for high-resolution device rendering

The cover is uploaded separately on the KDP publishing page. But the EPUB manuscript should also contain an internal cover image (marked with properties="cover-image" in the OPF manifest). The uploaded cover appears on the Amazon store page and product listing. The internal cover appears in the Look Inside preview and as the first "page" when opening the book.

If the uploaded cover and internal cover differ, the uploaded one takes priority on the store page. They should match to avoid confusing readers who see one cover on the store page and a different one when opening the book.

Interior Image Requirements

Images in the manuscript body (figures, illustrations, charts) have their own requirements:

  • Resolution: 300 DPI minimum for images that fill the screen width. Lower-res images render blurry on high-DPI Kindle screens (Kindle Paperwhite is 300 PPI)
  • File format: JPEG or PNG within the EPUB. Amazon converts internally during processing
  • Color space: RGB. Even for grayscale images, use RGB color space — Kindle handles the conversion for e-ink display
  • Maximum file size: Individual images should stay under 5MB. Total manuscript including all images should stay under 650MB
  • Inline vs floating: Kindle's renderer supports both inline images (in the flow of text) and block images (their own paragraph). Avoid CSS float for image positioning — Kindle's float support is inconsistent. Use block-level images centered with CSS text-align: center on the containing element

For books with many images (cookbooks, photography, children's books), the 650MB manuscript limit is generous but the per-MB delivery fee on 70% royalty books can add up. A 100MB ebook at 70% royalty costs $0.15/download in delivery fees. At $4.99, that's $0.15 of your $3.49 royalty gone to delivery costs.

Tables on Kindle: The Eternal Problem

Tables are the most consistently problematic element in Kindle formatting. Kindle's renderer handles simple tables (2-3 columns, short text per cell) adequately. Anything more complex degrades rapidly:

  • Wide tables (4+ columns): Kindle squeezes columns until text wraps excessively or becomes unreadable. On a 6-inch screen, there's physically not enough horizontal space for many columns of text
  • Nested tables: Support is unreliable. Some Kindle versions render them, others collapse or ignore them
  • Merged cells: colspan and rowspan work in AZW3/KFX but not in older MOBI. Keep it simple
  • Fixed-width tables: CSS width: 100% works. Pixel-width columns don't — Kindle overrides them to fit the screen

Strategies for table-heavy content: convert complex tables to images (screenshot at high resolution), use simplified layouts (single-column with labeled rows instead of multi-column grids), or publish as print replica (PDF upload) for content where tables are essential.

Always test tables in Kindle Previewer at the smallest screen size (phone). If a table is unreadable on a phone-sized screen, consider redesigning it. Your readers will encounter it on every screen size Kindle supports.

Testing with Kindle Previewer 3

Kindle Previewer 3 is a free desktop application (Windows/Mac) that simulates how your book renders on Kindle devices and apps. It's the single most important QA tool for Kindle publishing.

How to Use Kindle Previewer

Open your EPUB, DOCX, or KPF in Kindle Previewer. It converts the file using the same pipeline KDP uses and shows the output in three simulated devices:

  • Kindle E-reader — 6-inch e-ink display, grayscale rendering. This is where most prose is read. Check: text readability, chapter navigation, image rendering in grayscale
  • Kindle Fire Tablet — Color display, larger screen. Check: color image quality, table rendering, cover appearance
  • Kindle App (phone) — Smallest screen. Check: table readability, image sizing, overall usability on a small display

The previewer also shows: enhanced typesetting simulation (KFX rendering), TOC navigation, page count estimates, and quality warnings. Any warning that appears in Kindle Previewer will also trigger during KDP upload — fix warnings locally before uploading.

Common Issues Found in Preview

  • Missing cover — No cover-image property in the OPF, or the cover image path is wrong
  • Broken TOC — Navigation links that don't resolve to content. Usually caused by changed filenames without updating the nav document
  • Image quality warnings — Images below 300 DPI for their displayed size. Replace with higher-resolution versions
  • Excessive file size — Large uncompressed images. Optimize JPEGs to quality 85, strip unnecessary PNG metadata
  • Encoding issues — Non-UTF-8 characters. Ensure all XHTML files are UTF-8 encoded
  • CSS unsupported properties — Flexbox, grid, and some CSS3 properties aren't supported by Kindle's renderer. Stick to CSS2 with basic CSS3 (font-face, basic transforms, text-shadow)

What Amazon Does to Your File

Understanding Amazon's internal conversion helps explain why your EPUB looks different on Kindle than in Apple Books or Calibre:

  1. Validation — epubcheck for EPUB, internal validation for DOCX/KPF
  2. HTML normalization — Amazon sanitizes the HTML, removing unsupported elements and properties
  3. CSS processing — Unsupported CSS is stripped. Amazon adds their own CSS for enhanced typesetting
  4. Image processing — Images are re-encoded and optimized for device-specific rendering (grayscale versions for e-ink, full color for tablets)
  5. Font handling — Embedded fonts are processed. Amazon may substitute fonts that fail licensing validation
  6. KFX generation — The final output uses Amazon's Ion binary format with enhanced typesetting features
  7. Fallback generation — Amazon also creates AZW3 versions for older devices that don't support KFX

The key insight: you don't control the final output format. You control the input, and a cleaner input produces a cleaner output. This is why EPUB (where you control the exact HTML/CSS) outperforms DOCX (where Amazon interprets Word formatting).

Kindle publishing is a solved problem in 2026. Create a clean EPUB3, embed a high-resolution cover, validate with epubcheck, test with Kindle Previewer, and upload. Amazon handles the conversion to their delivery format. The era of needing to know the intricacies of MOBI headers or AZW3 container formats is over.

Where problems still occur is at the edges: complex tables, heavily styled content, and print-layout documents forced into reflowable format. For those cases, the answer is usually to simplify the content (redesign tables, reduce CSS complexity) or to publish as a print replica (PDF upload). The Kindle renderer is good but not as capable as a web browser — design for its constraints, and your readers get a good experience.