ePub 3 vs. ePub 2 for Amazon KDP: Why Kindle Officially Requires ePub 3 (And What Breaks in Legacy Files)

1. The Death of MOBI and ePub 2: Why Amazon Overhauled Its Kindle Ingestion Engine

ePub 3 is now the mandatory upload standard for Amazon KDP because it carries native XHTML5 semantics, CSS3 typography, and MathML that Amazon's converter maps cleanly into KFX. ePub 2 and legacy .mobi files lack these structures, so the ingestion engine strips styling, flags warnings, and can reject the file outright.

That capsule answers the query in one breath, but the mechanics behind it took Amazon roughly two decades to build. Understanding the pipeline matters because the file you upload is not the file readers download. Every manuscript passes through a conversion engine that either preserves your typography or quietly destroys it. The difference between a professionally set 6x9" trade paperback and a mangled Kindle file usually comes down to which container format you fed the machine.

The Legacy Era: Mobipocket, KF7, and the HTML3 Ceiling

Amazon acquired Mobipocket in 2005 and inherited its .mobi container and .prc reader format. The Kindle Format 7 (KF7) rendering engine that shipped with early Kindle devices was built on a stripped-down HTML 3.2 subset. No external stylesheets. No cascading inheritance. Font sizes were expressed as absolute values against a fixed baseline, which meant a heading tagged <h2> rendered at one size on a Kindle Keyboard and a visibly different size on a Kindle DX. Margins were device-controlled, not author-controlled. Drop caps, hanging indents, and small caps simply did not exist in the rendering vocabulary.

Writers adapted by accepting the ceiling. A 2010-era nonfiction book uploaded as .mobi might contain 60,000 words and zero styling decisions beyond bold and italic. Chapter headings were simulated with centered capital letters. Block quotes were indented using non-breaking spaces. The format worked, barely, because every reader saw the same crude approximation.

The math on file size was equally primitive. Mobipocket compressed text aggressively, and embedded images were capped near 127 KB per asset in older firmware. A 300-page book with 40 interior figures could balloon past the practical ceiling, forcing authors to downscale screenshots to 72 DPI—well below the 300 DPI threshold that print production demands.

The Intermediate Era: ePub 2 and Its Fragile Compromises

ePub 2 arrived as an IDPF specification built on XHTML 1.1 and CSS 2.1. It introduced the NCX file (Navigation Control file for XML) for table-of-contents logic and a manifest/opf structure that separated content from metadata. For the first time, an author could define a stylesheet, link it, and expect consistent rendering across compliant readers.

Amazon's support for ePub 2 was always indirect. KDP accepted .doc and .docx and converted them server-side, or accepted ePub 2 through third-party tools. The conversion to KF8 (Kindle Format 8, the intermediate engine) handled basic CSS but broke on anything ambitious. Floating elements collapsed. Fixed-position boxes were discarded. Web fonts loaded inconsistently because the older engine refused to embed certain font families without explicit obfuscation.

Multimedia was the loudest failure. ePub 2 supported audio and video tags in theory, but Amazon's converter dropped them silently. An author who embedded a 90-second interview clip in an ePub 2 file would upload successfully, preview the file, and find a blank rectangle where the player should be. No error message. No warning. Just a missing asset.

Amazon's Deprecation Announcement and the KFX Endgame

In late 2021, Amazon notified publishers that .mobi and .prc uploads would be retired. The cutoff landed in 2022: KDP stopped accepting MOBI files for new titles and reflowable ePub 2 files began triggering ingestion warnings. The stated reason was consolidation. The real reason was KFX.

Kindle Format 10, marketed as KFX, is Amazon's proprietary rendering format. It supports advanced typography features—kerning pairs, ligatures, hyphenation dictionaries, and enhanced typesetting—that neither MOBI nor ePub 2 could express. But KFX is not an upload format. Authors upload ePub 3, and Amazon's converter translates it internally into KFX before delivery.

This two-stage pipeline is where most formatting disasters originate. The converter reads your ePub 3 structure and makes judgment calls. Clean semantic markup survives. Ambiguous markup gets normalized into the lowest common denominator.

What Happens When You Upload a Legacy File Today

Suppose an author exports a manuscript from a 2014-era word processor as .mobi and drags it into the KDP dashboard. Three failures cascade in sequence.

1. Ingestion warning flags. The dashboard displays a compatibility notice. The file may still process, but the warning signals that the converter is entering fallback mode.
2. Formatting strip-downs. Custom margins collapse to device defaults. Embedded fonts are replaced with the system serif. Drop caps, small caps, and letter-spacing rules vanish. Tables lose their borders. A book that looked like a $24.99 trade paperback in preview renders like a plain text file.
3. Potential rejection. Files with malformed OPF manifests, missing NCX references, or unencoded ampersands can fail conversion entirely. The author receives a generic error and no diagnostic detail.

The Royalty Math That Makes Formatting Non-Negotiable

Formatting failures are not cosmetic. They are financial. Amazon's 6x9" print royalty formula is:

A 280-page 6x9" paperback listed at $16.99 earns:

Now consider that a 280-page book requires a 0.500" gutter margin because it falls in the 151–300 page band. If a broken ePub 2 conversion forces the layout to reflow and adds 40 pages of unintended whitespace, the page count jumps to 320. The gutter requirement climbs to 0.625", the print cost rises to $4.69, and the per-copy royalty drops to $5.504—a 8.0% haircut on every sale. Multiply that across 5,000 lifetime units and the formatting error costs $2,400.

The 0.375" gutter applies under 150 pages. The 0.500" band covers 151–300. The 0.625" band covers 301–500. Anything past 501 pages demands 0.750". These are not suggestions. They are binding constraints that determine whether your inner text sits safely inside the trim or bleeds into the binding.

The Modern Standard: ePub 3 as the Only Viable Container

ePub 3 solves every architectural failure of its predecessors. It uses XHTML5, which means semantic elements like <section>, <aside>, and <figure> carry meaning the converter can interpret. It uses CSS3, which means @font-face embedding, flexible box layouts, and media queries actually render. It requires a nav.xhtml document with the epub:type="toc" attribute, and it supports the spine linear attribute to control reading order.

Metadata lives in Dublin Core elements inside the OPF package file: dc:title, dc:creator, dc:identifier with a UUID or ISBN, and dc:language. These fields feed Amazon's catalog system directly. Missing or malformed Dublin Core entries cause listing errors that delay publication by days.

Every ePub 3 file should pass epubcheck validation with zero errors before it touches KDP. Warnings about deprecated NCX fallbacks are acceptable. Errors about missing nav documents, broken internal links, or undeclared namespaces are not.

The transition from MOBI to ePub 3 was not a cosmetic upgrade. It was a structural rebuild of how Amazon ingests, converts, and delivers digital text. Authors who understand the pipeline produce files that render correctly on every device. Authors who ignore it produce files that Amazon silently degrades. The gap between those two outcomes is measured in royalties.

2. Under the Hood: Semantic HTML5, nav.xhtml, and Why Kindle Rejects Old Table of Contents

Amazon's Kindle Previewer 3 does not fail a book because the prose is weak. It fails the file because the container is malformed. The single most common rejection trigger for self-published reflowable titles is a navigation document that survives on one platform and collapses on another. To understand why, you have to look at the actual bytes inside the .epub container — specifically the difference between the ePub 2 navigation model and the ePub 3 navigation model.

An .epub file is a ZIP archive with a mandated first entry: an uncompressed mimetype file containing the ASCII string application/epub+zip. Strip the extension, rename it to .zip, and you can inspect everything. What you find inside dictates whether Kindle Direct Publishing accepts the upload or bounces it back with a generic "We couldn't convert your file" message.

ePub 2 and the Legacy toc.ncx

ePub 2, formalized under the Open eBook Forum in 2002 and ratified as an OPS 2.0 specification, relied on a file called toc.ncx — the Navigation Control file for XML. NCX is a DAISY Consortium format, originally built for talking-book players with physical buttons. It is verbose, order-dependent, and unforgiving. Every entry needs a playOrder attribute, a unique id, a navPoint wrapper, a navLabel, a nested text node, and a content element pointing at a source file. Miss one playOrder integer in a 40-chapter book and some readers silently drop the back half of your table of contents.

Here is what a three-chapter toc.ncx actually looks like:

<?xml version="1.0" encoding="UTF-8"?>
<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/"
     version="2005-1">
  <head>
    <meta name="dtb:uid" content="urn:isbn:9781234567890"/>
    <meta name="dtb:depth" content="1"/>
    <meta name="dtb:totalPageCount" content="0"/>
    <meta name="dtb:maxPageNumber" content="0"/>
  </head>
  <docTitle><text>The Lean Publishing Playbook</text></docTitle>
  <navMap>
    <navPoint id="np-1" playOrder="1">
      <navLabel><text>Chapter One</text></navLabel>
      <content src="ch01.xhtml"/>
    </navPoint>
    <navPoint id="np-2" playOrder="2">
      <navLabel><text>Chapter Two</text></navLabel>
      <content src="ch02.xhtml"/>
    </navPoint>
    <navPoint id="np-3" playOrder="3">
      <navLabel><text>Chapter Three</text></navLabel>
      <content src="ch03.xhtml"/>
    </navPoint>
  </navMap>
</ncx>

Three chapters. Forty-two lines. Now multiply that by a 28-chapter business book with front matter, part dividers, and an index. You land near 400 lines of XML that no human wants to hand-edit. Worse, the playOrder sequence is fragile: reorder a chapter and every downstream integer needs renumbering. If you insert a new chapter between np-14 and np-15, every subsequent navPoint shifts by one. Get it wrong, and Kindle's conversion pipeline renders a table of contents that jumps from Chapter 14 directly to Chapter 16.

ePub 3 and the nav.xhtml Document

ePub 3.0 shipped in 2011; ePub 3.3 is the current IDPF/W3C recommendation. The specification replaced toc.ncx with nav.xhtml — a standard XHTML5 document that uses the HTML5 <nav> element with an EPUB-specific attribute: epub:type="toc". The same file can carry multiple navigation blocks, each identified by its own epub:type value.

The equivalent three-chapter nav.xhtml is dramatically leaner:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:epub="http://www.idpf.org/2007/ops"
      xml:lang="en" lang="en">
<head>
  <meta charset="utf-8"/>
  <title>Table of Contents</title>
</head>
<body>
  <nav epub:type="toc" id="toc">
    <h1>Contents</h1>
    <ol>
      <li><a href="ch01.xhtml">Chapter One</a></li>
      <li><a href="ch02.xhtml">Chapter Two</a></li>
      <li><a href="ch03.xhtml">Chapter Three</a></li>
    </ol>
  </nav>
  <nav epub:type="landmarks" hidden="hidden">
    <ol>
      <li><a epub:type="cover" href="cover.xhtml">Cover</a></li>
      <li><a epub:type="titlepage" href="title.xhtml">Title Page</a></li>
      <li><a epub:type="bodymatter" href="ch01.xhtml">Start Reading</a></li>
    </ol>
  </nav>
</body>
</html>

No playOrder. No navPoint wrappers. No navLabel/text nesting. Order is implied by document order inside the <ol>. Insert a chapter and you add one <li>. That is the entire edit. ePub 3 navigation is both human-readable (a person can scan it) and machine-readable (the <ol> structure maps directly to the reading system's TOC panel).

The landmarks block is the second half of the equation, and most self-publishers skip it. Landmarks tell the reading system where the cover, title page, and start of body matter live. Amazon's "Go To" menu and Apple Books' navigation drawer both read these declarations. Without a bodymatter landmark, the reader's "Start Reading" button drops the user on the copyright page instead of Chapter One. That is a one-line fix that costs nothing and prevents a one-star review.

Why Amazon Still Demands a Fallback NCX

Here is the counterintuitive part. Amazon accepts ePub 3 uploads through KDP, but the KindleGen and Kindle Previewer conversion pipeline silently generates a toc.ncx inside the .mobi or .azw3 output regardless of whether you supplied one. Why? Legacy hardware. The Kindle Keyboard (third generation, released 2010) and the original Kindle DX run firmware that predates ePub 3 entirely. Their navigation engine reads NCX, full stop. If your ePub 3 file contains only nav.xhtml and no toc.ncx, Amazon's converter synthesizes one — and sometimes synthesizes it badly, flattening nested TOCs or dropping entries past the first level.

The safe production rule: ship both. Include nav.xhtml as the primary navigation document, declared in the OPF manifest with the property properties="nav", and include a hand-authored toc.ncx as a fallback. The OPF <spine> element then references the NCX via the toc attribute. This dual-navigation pattern passes epubcheck 5.x validation cleanly and survives conversion to every Kindle generation from the Keyboard forward.

Side-by-Side: ePub 2 vs. ePub 3 Structure

The following table isolates the exact differences that matter during production. Every row reflects a real divergence in the OPF package document, the metadata schema, or the spine declaration.

The Package Document Manifest, Line by Line

The manifest is where the nav declaration lives. In ePub 3, the navigation document must appear as a manifest item with the property flag:

<manifest>
  <item id="nav" href="nav.xhtml"
        media-type="application/xhtml+xml"
        properties="nav"/>
  <item id="ncx" href="toc.ncx"
        media-type="application/x-dtbncx+xml"/>
  <item id="ch01" href="ch01.xhtml"
        media-type="application/xhtml+xml"/>
</manifest>
<spine toc="ncx">
  <itemref idref="cover" linear="no"/>
  <itemref idref="ch01" linear="yes"/>
</spine>

Two details trip up first-time builders. First, the toc="ncx" attribute on <spine> must match the manifest item id of the NCX file exactly — not the filename, the id. Second, the linear="no" attribute on the cover itemref tells the reading system to skip the cover during linear reading progression while still rendering it in the navigation. Omit linear="no" and some readers will open your book on the cover image and stall there, waiting for a page turn that the user does not know to make.

The Cost of Getting

3. CSS3 Typography Support: Drop Caps, Callout Boxes, Math Formulas, and Responsive Breakpoints

ePub 3 is not a "better ePub 2." It is a different rendering contract. Under the EPUB 3.3 specification, a reading system is expected to honor a substantial subset of CSS3, including custom fonts, pseudo-element selectors, border-radius, box-shadow, and media queries. Under EPUB 2, the same CSS is treated as advisory. Amazon's Kindle pipeline historically stripped or silently ignored most of it, then re-flowed what remained into a single column of plain paragraphs. For a non-fiction author, that difference is the gap between a designed page and a text dump.

This section covers exactly what you can build — and exactly what breaks when the same file is read on an older engine.

Drop Caps That Survive Reflow

A drop cap is the single most requested non-fiction typographic flourish. It is also the easiest thing to get wrong, because the naive implementation — wrapping the first letter in a <span class="dropcap"> — hard-codes a letter into your markup and breaks the moment you edit the paragraph.

The correct approach uses the ::first-letter pseudo-element. It targets the first typographic letter of the block automatically, so your markup stays clean and your edit history stays sane.

p.chapter-open::first-letter {
  font-family: "Playfair Display", Georgia, serif;
  font-size: 3.4em;
  line-height: 0.8;
  float: left;
  padding: 0.08em 0.12em 0 0;
  color: #1a1a1a;
}

/* Kindle-safe fallback: no float, no oversized glyph */
@media amzn-mobi {
  p.chapter-open::first-letter {
    font-size: 1em;
    float: none;
    padding: 0;
  }
}

Two engineering notes. First, line-height: 0.8 is not decorative — it prevents the enlarged glyph from pushing the first line downward and creating an uneven baseline. Second, the @media amzn-mobi block is a real Amazon-specific media query. Older Kindle conversion targets honor it and will flatten the drop cap rather than mangle it. Without that block, the drop cap can overlap the following text on a narrow e-ink viewport.

Callout Boxes: Tips, Warnings, Case Studies

Non-fiction lives on callouts. A 6x9" trade paperback uses them to break a wall of body copy; an ePub needs them to survive a 320-pixel-wide phone screen and a 12.9-inch iPad Pro at the same time. Border-radius, a tinted background, and a restrained box-shadow do this without any image assets.

.callout-box {
  border-radius: 6px;
  padding: 0.85em 1em;
  margin: 1.4em 0;
  font-size: 0.95em;
  line-height: 1.45;
  page-break-inside: avoid;
}

.callout-tip {
  background: #eef6f0;
  border-left: 4px solid #2f7d4f;
  color: #14301f;
}

.callout-warning {
  background: #fdf3e7;
  border-left: 4px solid #b5651d;
  color: #3a2109;
}

.callout-case {
  background: #f2f4f8;
  border-left: 4px solid #3b4a6b;
  color: #1b2233;
}

Keep page-break-inside: avoid on every callout. On a 300-page book, a warning box split across a page turn reads as a typo. The property is honored by Kindle's KFX renderer and by Apple Books; where it is ignored, the callout still renders correctly, just possibly split.

Responsive Tables for 6-Inch and 12.9-Inch Screens

Tables are where ePub 2 fails hardest. A four-column financial table at 100% width on a 6-inch e-ink screen overflows the right margin, and the reader cannot scroll horizontally on most devices. The fix is not "make the font smaller." The fix is a media query that converts the table into stacked rows below a breakpoint.

table.data {
  width: 100%;
  border-collapse: collapse;
  font-size: 0.92em;
}

table.data th,
table.data td {
  padding: 0.5em 0.6em;
  border-bottom: 1px solid #d9dde3;
  text-align: left;
}

@media screen and (max-width: 520px) {
  table.data thead { display: none; }
  table.data tr {
    display: block;
    margin-bottom: 1em;
    border: 1px solid #d9dde3;
    border-radius: 4px;
  }
  table.data td {
    display: block;
    border: none;
    padding: 0.35em 0.7em;
  }
  table.data td::before {
    content: attr(data-label) ": ";
    font-weight: 600;
    color: #4a5568;
  }
}

The data-label attribute carries the column header into each stacked cell, so the reader never loses context. On a 12.9-inch iPad the media query does not fire and the table renders in its full four-column form. On a 6-inch Kindle with a 520-pixel viewport, it becomes a vertical card stack.

Web Font Embedding and Fallback Stacks

Embedding a font requires a valid @font-face rule and a font file declared in the OPF manifest with the correct media type. A missing manifest entry is the single most common cause of a font silently reverting to the reader's default.

@font-face {
  font-family: "Booklier Serif";
  src: url("../fonts/BooklierSerif.woff2") format("woff2"),
       url("../fonts/BooklierSerif.woff")  format("woff");
  font-weight: normal;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Booklier Serif", Georgia, "Times New Roman", serif;
}

code, pre {
  font-family: "IBM Plex Mono", "Courier New", monospace;
}

Always terminate a font stack with a generic family — serif, sans-serif, or monospace. If the embedded file fails to load on a legacy device, the generic fallback guarantees a readable page instead of a blank one.

What Breaks in ePub 2

Three failures recur. First, Kindle's legacy renderer strips unsupported CSS declarations and collapses callout boxes into unstyled body paragraphs — your warning box becomes a sentence with no visual weight. Second, tables lose their width constraint and overflow off the right edge, with no horizontal scroll available. Third, @font-face is discarded entirely, so your carefully chosen typeface reverts to the device default.

The practical rule: write for ePub 3, but never assume ePub 3. Every callout needs a readable fallback. Every table needs a stacked mode. Every font needs a generic tail. Do that and the same file renders correctly on a 2013 Kindle Paperwhite and a 2024 iPad Pro — which is exactly the range your readers actually own.

4. Accessibility Standards & Dublin Core: Screen Readers, Readium Engines, and Amazon Compliance

An ePub 3 file is a ZIP archive of XHTML documents, and every one of those documents is a web page wearing a book's clothing. That single fact governs everything in this section. Screen readers, Readium-based reading engines, Apple's Books renderer, and Amazon's Kindle conversion pipeline all parse your XHTML the same way a browser parses a webpage. If your markup is garbage, your book is garbage to a blind reader. Metadata is how the retail systems decide whether to surface your title to those readers at all.

Two files do the heavy lifting: the content.opf package document and the nav.xhtml navigation document. Get them wrong and epubcheck fails. Get them right and your book passes through Amazon's ingest, Apple's Transporter, and Kobo's validation without a single rejection email.

Dublin Core Metadata in the .opf File

The <metadata> block inside content.opf carries Dublin Core elements. These are not optional decoration. Retail systems read them to populate product pages, and library systems read them to build catalog records.

The dcterms:modified field is the one authors forget and the one that breaks everything. It must be UTC, it must end in Z, and it must not carry fractional seconds. A value of 2025-03-14T09:22:00.000Z fails epubcheck. So does 2025-03-14 09:22 with a space. Every time you rebuild the file, bump this timestamp. Amazon uses it to detect whether a re-uploaded manuscript is genuinely new.

Accessibility Metadata: EPUB Accessibility 1.1 and schema.org

EPUB Accessibility 1.1 defines three metadata families, expressed in the content.opf using the schema.org vocabulary. These are declared as meta property entries.

• accessMode — how the content is consumed. Values: textual, visual, auditory, tactile. A standard text-only novel declares textual. A cookbook with photographs declares textual and visual.
• accessibilityFeature — what assistive affordances exist. Values include alternativeText, structuralNavigation, tableOfContents, readingOrder, printPageNumbers, longDescription, MathML, describedMath, transcript.
• accessibilityHazard — flags content that can harm. Values: flashing, motionSimulation, sound, none. A book with no animated or flashing content declares none.

A compliant block for a text-heavy trade paperback with figures looks like this:

<meta property="schema:accessMode">textual</meta>
<meta property="schema:accessMode">visual</meta>
<meta property="schema:accessModeSufficient">textual</meta>
<meta property="schema:accessibilityFeature">structuralNavigation</meta>
<meta property="schema:accessibilityFeature">alternativeText</meta>
<meta property="schema:accessibilityFeature">tableOfContents</meta>
<meta property="schema:accessibilityFeature">readingOrder</meta>
<meta property="schema:accessibilityHazard">none</meta>
<meta property="schema:accessibilitySummary">All figures carry alt text. Reading order is linear.</meta>

The accessModeSufficient entry deserves its own sentence. It tells the reading system which single mode is enough to consume the whole book. For a text-only title, textual alone suffices. For a book where the figures carry data not repeated in prose, you cannot claim textual alone is sufficient, and you must either add longDescription entries or accept that the title requires both modes.

Why Amazon and Apple Prioritize Accessible Titles

Neither retailer publishes its ranking algorithm. Both publish their ingest rules, and those rules reveal the priority. Amazon's Kindle Previewer flags missing alt text on images as a quality warning that blocks "Quality Notices" clearance on some categories. Apple's Transporter rejects ePub files that declare accessibilityFeature values inconsistent with the actual document contents — claim alternativeText and ship an <img> with no alt attribute, and the upload fails validation.

The commercial math is not mysterious. Roughly 7.6 million Americans report a visual disability, and the global figure exceeds 250 million. Retailers that surface accessible titles capture that demand and reduce returns. A title flagged accessible gets indexed in Apple's "Accessibility" browse category, which is a zero-cost discovery channel. Amazon's search ranking weights completion rate and return rate; accessible books get finished more often and returned less. The metadata costs you thirty minutes and two dozen lines of XML.

Semantic HTML: What Screen Readers Actually Announce

Screen readers do not read tags. They read the accessibility tree that the reading engine builds from those tags. Readium's engine, used by Thorium, Kobo, and several library platforms, maps HTML5 landmark and sectioning elements to ARIA roles. Get the semantics right and the reader hears "navigation," "complementary," "figure," and "article" as structural cues.

A chapter should open with <section role="doc-chapter" aria-labelledby="ch4-head">, then an <h2 id="ch4-head">. The doc-chapter role comes from the DPUB-ARIA module and is the correct vocabulary for book content. Generic <div> soup forces the screen reader to announce nothing at all, which means a blind reader hears the sidebar text as if it were body copy. That is a content failure, not a cosmetic one.

Run every build through epubcheck 5.x before upload. A clean validation report, correct dcterms:modified, and honest accessibility metadata are the three-line proof that separates a professional ePub 3 from a renamed HTML file. Amazon's ingest, Apple's Transporter, and every library acquisition system read that proof before a human ever sees your cover.

5. Pre-Flight Validation: How to Test Your Package Against epubcheck 5.1 Before Uploading to KDP

Amazon's Kindle Direct Publishing ingestion pipeline is not a validator. It is a converter. KDP will accept a malformed ePub 3 file, process it through KindleGen-derived tooling, and hand you back a KPF or MOBI artifact with silently mangled structure. Missing anchors become dead links. Unmanifested images vanish. Alt text disappears. You will not receive an error message. You will receive a published book with defects you cannot see until a reader emails you a screenshot.

epubcheck 5.1 is the firewall between your working directory and that pipeline. It is the reference implementation of the EPUB 3.3 specification, maintained by the W3C after the IDPF merged into it in 2017. The tool is a Java application distributed as epubcheck-5.1.0.zip from the DAISY Consortium and the W3C GitHub repository. It parses your container, walks every XHTML document, validates the OPF package manifest, checks the navigation document against the spine, and reports errors by severity class: FATAL, ERROR, WARNING, INFO, USAGE.

Run it before every upload. Not after a rejection. Before.

Installing epubcheck 5.1

You need Java Runtime Environment 11 or later. Verify with java -version in Terminal (macOS/Linux) or Command Prompt (Windows). If you see openjdk version "17.0.9" or similar, you are ready. If not, install Adoptium Temurin 17 LTS.

Download epubcheck-5.1.0.zip, unzip it, and note the path to epubcheck.jar. On macOS, a typical path is /Users/yourname/tools/epubcheck-5.1.0/epubcheck.jar. On Windows, C:\epubcheck\epubcheck-5.1.0\epubcheck.jar.

Two Ways to Run It

The command-line invocation returns an exit code. Zero means clean. One means errors present. Two means a fatal condition prevented validation entirely. Wire that exit code into your build script: java -jar epubcheck.jar book.epub || exit 1. Now a broken file cannot reach KDP by accident.

To validate an unpacked directory instead of a zipped ePub, pass the folder path: java -jar epubcheck.jar ./OEBPS-root/. This is faster during iterative editing because you skip the zip/unzip cycle on every pass.

The Five Errors That Break Kindle Conversions

Across thousands of validated packages, five error codes account for the overwhelming majority of KDP ingestion failures. Learn them by heart.

1. RSC-005 — Unmanifested File in the Container

Every file inside the ePub OEBPS/ directory must appear as an <item> in the OPF manifest, referenced by a unique id and an href. A stray cover-backup.jpg left in the images folder triggers RSC-005.

The error text reads: RSC-005: Error while parsing file: 'cover-backup.jpg' is not declared in the OPF manifest. The fix is mechanical. Either delete the orphan file or add the manifest entry:

Check the reverse too: a manifest entry whose href points to a file that does not exist produces the same class of error. Grep your OPF for every href value and confirm each file exists on disk.

2. MED-003 — Unsupported Media Type

EPUB 3.3 permits a defined set of core media types: JPEG, PNG, GIF, SVG, WebP (with caveats), and WOFF2 for fonts. TIFF, BMP, HEIC, and raw uncompressed formats are not core. A TIFF dropped into the images folder produces:

MED-003: The image file 'figure-03.tif' does not appear to be a valid image of a core media type.

Convert to PNG or JPEG. For color figures, JPEG at quality 85 keeps file size low. For line art and diagrams, PNG-8 with indexed color. WebP is permitted in EPUB 3.3 but Kindle Previewer 3 does not render WebP on older Paperwhite firmware (5.12 and earlier), so include a JPEG fallback via the <picture> element or avoid WebP entirely for KDP-bound files.

3. NAV-003 — Navigation Target Does Not Exist

Your nav.xhtml contains a table of contents with internal links. Each <a href="chapter-04.xhtml#section-4-2"> must resolve to an element with id="section-4-2" in that file. If you renamed a heading and forgot to update the anchor, epubcheck reports:

NAV-003: Fragment identifier is not defined: 'section-4-2'.

This error is invisible in most reading apps. The link simply does nothing. Kindle Previewer will not flag it. Only epubcheck catches it. Open the target XHTML, find the heading, and confirm the id attribute matches the fragment exactly, character for character. Case matters. Section-4-2 and section-4-2 are different identifiers.

4. CSS-008 — Undefined Property or Vendor-Prefix Syntax Error

epubcheck validates CSS against the CSS 2.1 and CSS 3 modules that EPUB 3.3 supports. Two frequent triggers:

• Undefined property: CSS-008: The property '-webkit-text-stroke' is not defined in any CSS specification. Vendor-prefixed properties trigger warnings, not fatal errors, but they signal code that Kindle's converter may drop.
• Syntax error: A missing semicolon or unmatched brace. CSS-008: Unexpected token '}' at line 142.

Strip vendor prefixes unless you can justify them. Replace -webkit-border-radius with border-radius. Replace -moz-box-shadow with box-shadow. Kindle's rendering engine is based on a fork of WebKit, and modern prefixes are unnecessary for KDP targets.

5. ACC-001 — Missing Alt Text on Content Images

Accessibility validation is not optional in EPUB 3.3. Every <img> element requires an alt attribute. Decorative images require alt="" explicitly, not an omitted attribute. The error:

ACC-001: The 'img' element is missing a required 'alt' attribute.

Fix every instance. For a 240-page trade paperback with 38 figures, that is 38 alt attributes. Write them. A figure of a scatter plot needs alt="Scatter plot showing conversion rate rising from 2.1% to 4.7% across six months", not alt="chart". Screen readers read the alt text aloud; vague text serves no one.

Reading the epubcheck Report

The default output is a plain-text stream. Errors appear in document order, not severity order. Pipe it through a sort to prioritize:

This gives you an error frequency table. The top line is your highest-count defect. Fix that first. Re-run. Repeat until the output reads No errors or warnings detected.

Warnings are not blockers for KDP, but they are leading indicators of future rendering problems. A WARNING: CSS-007 about an unrecognized property today becomes a broken layout in Kindle Previewer tomorrow. Treat warnings as a backlog, not as noise.

Testing in Kindle Previewer 3

epubcheck validates conformance to the spec. Kindle Previewer 3 validates rendering on Amazon's actual device profiles. You need both. A file can pass epubcheck cleanly and still render badly on a Kindle Oasis because of fixed-position CSS or unsupported font embedding.

Download Kindle Previewer 3 from kdp.amazon.com/en_US/help/topic/G202131200. It is available for macOS and Windows. Open your .epub file, then use the device dropdown in the top toolbar to cycle through every target:

In each profile, walk the full table of contents, tap every internal link, and scroll to the last page. The Kindle Previewer's "Quality Issues" panel (View → Quality Issues) surfaces additional problems that epubcheck cannot see: oversized images, missing cover, and font licensing restrictions.

Pre-Upload Checklist

1. Run java -jar epubcheck.jar book.epub. Confirm exit code 0 and "No errors or warnings detected."
2. Open in Kindle Previewer 3. Cycle through all five device profiles.
3. Tap every TOC entry. Confirm no dead links.
4. Check the Quality Issues panel. Resolve every flag.
5. Verify cover image is 1600 x 2560 px, RGB, JPEG, under 50 MB.
6. Confirm the OPF dc:identifier is a valid ISBN-13 or a stable UUID.
7. Upload the validated .epub to KDP. Select "Look Inside" preview. Walk it once more.

Seven steps. Roughly twelve minutes for a 240-page book. That is the difference between a clean publish and a reader discovering a broken link on page 87.

6. Frequently Asked Questions: ePub 3 Conversion, Kindle Previewer, and Common Errors

Every formatter fielding author emails eventually sees the same five questions. They arrive after the first upload fails, after Kindle Previewer throws a red X on page 214, or after a reader complains that the chapter headings render as 9-point gray text on a phone. The answers below are the ones I give paying clients, with the failure modes and the fixes spelled out.

1. Can I convert a Microsoft Word .docx directly into a valid ePub 3 file?

No. Not cleanly, and not without a sanitation pass. Word's "Save As > Web Page" and even its native export pipeline produce what formatters call tag soup: nested <span> elements carrying inline style attributes, empty <p> tags used as vertical spacers, and mso- prefixed CSS properties that no reading system recognizes.

A 68,000-word manuscript exported from Word routinely ships 340 KB of XHTML where the semantic content occupies 90 KB. The rest is dead weight. Worse, Word writes heading levels as paragraph styles rather than <h1>–<h6> elements, so the generated nav.xhtml table of contents either fails to build or builds with every entry pointing to the same anchor.

The repair sequence is mechanical:

1. Strip all inline styling with a parser that preserves only structural tags (p, em, strong, blockquote, ul, ol, li).
2. Map Word's paragraph styles to semantic HTML elements — "Heading 1" becomes <h1>, "Caption" becomes <p class="caption">.
3. Move every visual rule into a single external stylesheet.css.
4. Rebuild the OPF package document and the nav.xhtml file from the corrected heading tree.

Word can be the drafting tool. It cannot be the conversion engine. Treat the .docx as raw source, not as a finished container.

2. Is fixed-layout EPUB recommended for non-fiction books?

Rarely, and never for prose. Fixed-layout EPUB locks every element to an absolute X/Y coordinate on a canvas of fixed pixel dimensions — typically 1024×768 or 2048×1536. The reader cannot reflow text, cannot change the font size, cannot switch to a dark background, and cannot run the book through a screen reader. That is the correct behavior for a 32-page picture book or a comic where panel geometry carries meaning. It is the wrong behavior for a 250-page business book.

Consider what happens when a reader with presbyopia opens a fixed-layout non-fiction title on a 6-inch phone. The page scales down to roughly 4.2 inches of usable width. Body text that was set at 11 points on the layout canvas renders at approximately 6.8 points on the device. The reader pinches to zoom, drags the viewport around, and abandons the book at chapter two.

Reflowable EPUB solves this by letting the reading system own the typesetting. You supply structure and a stylesheet; the device supplies the viewport. Accessibility law in the EU and the US increasingly treats reflowability as a baseline requirement, not a feature. For non-fiction, the answer is reflowable, full stop.

3. Why does Amazon KDP change my EPUB file into a KFX file after upload?

KDP's ingestion pipeline converts your validated ePub 3 into KFX, Amazon's proprietary format for Kindle devices and apps. KFX powers Enhanced Typesetting — the hyphenation, kerning, and justified-text engine that makes Kindle books look professionally set rather than like a 1998 web page.

The conversion is automatic and non-optional. You upload EPUB; KDP delivers KFX. This matters because conversion failures do not always surface as errors. A book can pass KDP's initial validation, convert to KFX, and then render with dropped drop-caps, collapsed margins, or a broken table of contents on a specific device generation.

Two rules follow from this. First, run every manuscript through Kindle Previewer 3 before upload — it simulates the KFX rendering path and flags the exact issues KDP's converter will hit. Second, never rely on CSS that KFX discards. KFX ignores most position, float, and complex flex rules. Design for a linear, block-based flow and your book survives the conversion intact.

4. What image formats are safest for Kindle ePub 3?

JPEG and PNG. Nothing else. GIF, TIFF, BMP, and SVG either fail validation or render inconsistently across Kindle firmware generations. SVG in particular looks safe in a browser preview and then collapses to a blank rectangle on older Paperwhites.

Convert every CMYK asset to sRGB before packaging. A single CMYK JPEG inside an otherwise clean EPUB will render with inverted colors on Kindle and pass every validation check, because the validator does not inspect embedded color profiles. Catch it in the image pipeline, not after upload.

5. How does BooklierAi ensure 100% epubcheck 5.1 compliance?

BooklierAi compiles the manuscript through an automated semantic engine rather than hand-editing XML. The pipeline assigns Dublin Core metadata, generates nav.xhtml with correct epub:type attributes, sets the linear attribute on spine items, and writes a valid OPF 3.0 package document — all before the file reaches the validation gate.

Every export runs against epubcheck 5.1. Books pass on the first pass because the compiler never emits the constructs that trip the validator: no undeclared namespaces, no missing dc:identifier, no orphaned anchors, no malformed content.opf. You upload the finished file to KDP, and it converts to KFX without a single warning.

The practical result: authors spend their time on the manuscript, not on chasing XML errors at 2 a.m. The formatter's job is to make the file boring. A boring file validates, converts, and sells.