Confused about why KDP rejected your eBook with no clear reason? Here are the 11 formatting errors that trigger it and exactly how to fix each one.

Overview

You hit publish. Hours later, an email lands: “Your file did not pass automated formatting review.” Without any screenshot, without any line number, there is just a vague pointer toward “formatting issues” and a countdown clock on your launch date.

If you’re here, you’ve probably re-opened your manuscript for the third time, changed something you’re not even sure was wrong, and re-uploaded it to see if it works this time.

That guesswork is the actual frustration that has the power to burn you out.

The first thing you need to know is that KDP’s rejection system isn’t random.  There are some fix known set of rules against which an automated checker runs your file. Almost every rejection traces back to one of the eleven recurring errors mentioned in this blog. Below is each one of them, what it is, why the checker flags it, and how to fix it before a second (or third) rejection.

1. Fonts That Aren’t Embedded

Core Error: When your PDF mentions a font, but the font itself isn’t enclosed in the file.

Why KDP rejects it: This is the single and the most common cause of file rejection. When you export a document, most word processors and design tools embed fonts automatically. However, this is only the case when the font is licensed for embedding. A lot of complementary or downloaded fonts aren’t directly licensed for embedding, and your export tool will silently skip them rather than warn you.

How to fix it manually:

• Open your PDF’s document properties and check the fonts list.
• Each one of the fonts in the list should say “Embedded” or “Embedded Subset,” not just “Type 1” or “TrueType.”
• If a font isn’t embedded, either find a licensed-for-embedding version or consider other standard, safely embeddable typefaces (Garamond, Georgia, and Palatino are reliable defaults for body text).
• Re-export and check again before uploading.

2. Trim Size Mismatch

Core Error: When the page size of your PDF doesn’t match the trim size you selected during KDP setup.

Why KDP rejects it: The checker measures your PDF’s canvas in inches and compares it against the trim size on record. A file exported at 5″ x 8″ but compared against a 7″ x 10″ selection fails instantly. The software doesn’t guess your intent; it just compares numbers.

How to fix it manually:

• Confirm your document’s page size in your formatting tool matches your chosen trim size exactly before exporting (adding bleed dimensions only if you actually need bleed).
• Then use Acrobat or Preview to re-check the exported PDF’s page size. Don’t just rely on the source file, since export settings can silently override it.

3. Bleed Set Up Incorrectly (Or Applied When It Isn’t Required)

Core Error: Design elements like full-page images or a colored background extend to the edge of the page without the required bleed margin, or bleed has been added to a book that doesn’t need it.

Why KDP rejects it: Bleed exists because printers trim pages after printing, and anything meant to reach the true edge needs 0.125″ of extra margin on all sides to survive that cut without a visible white sliver. Text-only books with white margins don’t need bleed at all. Adding it anyway just shifts your whole layout and can trigger a size mismatch.

How to fix it manually:

• Expand your document 0.125″ beyond the trim size on every side of the page if any image or color is reaching its edge
• Make sure the artwork extends fully into that added margin, not just up to the original trim line.
• If nothing touches the edge, skip bleed totally, and keep your file at exact trim dimensions.

4. Low-Resolution Images

Core Error: The interior images are below 200 DPI at their displayed size.

Why KDP rejects it: KDP’s automated checker flags anything under 200 DPI outright. But here’s the part that catches authors off guard: images between 200 and 300 DPI often pass the automated check and still print soft or blurry. Because “passing the checker” and “looking good on the page” aren’t the same test. A 300 DPI image that gets resized larger in your layout effectively becomes a lower-DPI image at that new size.

How to fix it manually:

• Check each image’s resolution at the size it actually appears in your layout, not its original file size.
• Aim for a true 300 DPI at final display dimensions.
• Embed images directly rather than linking them from your hard drive
• Do not convert color images to greyscale deliberately for black-ink interiors. Color images printed in black ink often turn muddy if left untouched.

5. A Table of Contents That Doesn’t Navigate

Core Error: Tapping a chapter in the TOC does nothing, or lands in the wrong place.

Why KDP rejects it: A broken TOC almost always comes from typing out a contents page manually instead of generating one from heading styles. A manually typed list has no actual anchor links. It looks like a TOC to the human eye, but like nothing to Kindle’s navigation system. EPUB files need two TOCs to be valid: a visible HTML TOC with real clickable links, and a behind-the-scenes NCX/NAV structure that powers the Kindle “Go To” menu.

How to fix it manually:

• Apply proper heading styles (Heading 1, Heading 2) to every chapter title
• Then use your word processor’s automatic Table of Contents tool rather than typing entries by hand.
• After exporting to EPUB, open it in Kindle Previewer and tap every single TOC entry. If one doesn’t jump to the right page, the heading style wasn’t applied consistently there.

6. Inconsistent or Missing Heading Structure

Core Error: Chapter titles formatted by manually increasing font size instead of using actual heading styles.

Why KDP rejects it: This one is sneaky because it often doesn’t trigger an outright rejection; it triggers a broken TOC and inconsistent navigation, which does. AI-assisted and hastily formatted manuscripts are especially prone to this: text that looks like a heading because it’s bold and large, but carries no structural tag underneath.

How to fix it manually:

• Go through your manuscript and replace every manually sized “chapter title” with a genuine Heading 1 (or Heading 2 for subsections) style applied consistently.
• Consistency matters more than which specific style you choose; mixing manual sizing and real headings in the same document is what breaks the TOC generation.

7. Submitting a Word Document Directly for Print

Core Error: Uploading a .docx file where KDP expects a print-ready PDF.

Why KDP rejects it: For paperback and hardcover, Amazon converts DOCX files automatically, and that conversion is unreliable. Margins shift, fonts don’t embed the way they did in your original file, and images get downsampled without warning. What looks fine in Word can come out with irregular spacing and misaligned chapter openings once KDP’s converter touches it. If you’d rather not manage the DOCX-to-EPUB conversion yourself, our eBook conversion service handles the format conversion and validation for you.

How to fix it manually:

• Never submit DOCX for a print interior. Export to a proper print-ready PDF yourself, with all fonts embedded and images at full resolution.
• Check that the export nis ot using the source Word file before uploading.

 (For Kindle eBooks, EPUB is generally the safer, more structurally consistent choice over DOCX for the same reason.)

8. Margins Too Tight for Your Page Count

Core Error: An inside (gutter) margin that was fine at 150 pages but too narrow once the book grew to 400.

Why KDP rejects it: The gutter margin has to widen as page count increases. Because of the reason that a thicker book curves more at the spine and swallows more of the inside margin when opened. KDP’s minimums scale in steps, roughly 0.375″ for 24–150 pages, up to 0.875″ for books nearing 828 pages. A margin set once at the start of a project and never revisited is a common late-stage rejection trigger after a manuscript grows during editing.

How to fix it manually:

• Check your final page count after your last edit.
• Look up the correct gutter minimum for that count.
• Adjust your inside margin accordingly, with a little extra beyond the bare minimum for readability, since these are floors, not recommended values.

9. Password-Protected or Restricted PDFs

Core Error: A PDF exported with security settings, password protection, or copy restrictions enabled.

Why KDP rejects it: These files are rejected automatically, with no manual override. KDP’s system needs to read and process the file directly, and any protection layer blocks that outright.

How to fix it manually:

• Before exporting, confirm your PDF export settings have security and password protection turned off entirely.
• If you’re using a tool that adds protection by default, re-export with those options explicitly disabled.
• Verify by trying to open the file without a password yourself.

10. Crop Marks Left in the File

Core Error: Printer’s crop marks included in the exported PDF.

Why KDP rejects it: KDP handles trimming on its own end. Crop marks in your file are treated as stray marks inside the printable area rather than as production guides. This can throw off the automated layout check.

How to fix it manually:

• In your export settings, make sure crop marks, registration marks, and any other printer’s marks are switched off.
• Your submitted file should contain only the actual book content at the correct trim (or trim-plus-bleed) dimensions, nothing else.

11. An Odd Page Count (Paperback)

Core Error: A print interior with an odd total page count.

Why KDP rejects it: Paperbacks need an even page count for the printing process to lay out correctly, since pages print in facing pairs.

How to fix it manually:

• Add a single blank page at the end of your manuscript (a common spot is right before or after the back matter) to bring an odd count up to even.
• Re-check your final page total before export.

The Pattern Behind All Eleven

Look at that list again, and a pattern shows up. Almost none of these are content problems. They’re structural and technical ones. The kind that don’t show up when you’re staring at your manuscript on screen, only when an automated checker parses the file’s underlying code.

That’s exactly why the same errors keep recurring across thousands of independently formatted manuscripts every month. Manually re-uploading and hoping rarely fixes the actual cause.

Professional eBook formatters build files that account for all eleven of these from the start. They work from the specification sheet, not from how the manuscript looks on their own screen.

If you’d rather skip the resubmission cycle entirely, our eBook formatting service handles the full technical build so your file passes review on the very first attempt.

FAQ’s