Why is KDP rejecting my epub

You uploaded your book and KDP sent it back. Again.

The error message is vague, your file looks fine on your screen, and you have no idea what's actually broken. This is one of the most frustrating parts of self-publishing - and it happens to almost every indie author at least once.

The good news is that KDP almost never rejects books because of your writing. It rejects them because of technical details in the file itself. And those details are fixable once you know what to look for.

Here's every common reason KDP rejects an EPUB - and exactly how to fix each one.

Your File Isn't Actually a Valid EPUB

This sounds obvious but it's more common than you'd think. You named the file .epub but that doesn't mean it actually is one.

An EPUB file is a ZIP archive with a specific internal structure. It needs a mimetype file as the first entry, a META-INF/container.xml file pointing to the OPF package document, and a correctly formatted OPF file listing all your content.

Some tools export files that look like EPUBs but have a broken container structure inside. If you converted from Word using a basic converter and something glitched during export, KDP checks the real structure - not just the filename - and kicks it back immediately.

The fix is running your file through EPUB Check before uploading. It tells you within seconds whether your file is structurally valid. If the container is broken, you'll need to re-export from your source file rather than trying to patch the broken one.

Your Cover Image Dimensions Are Off

KDP has specific requirements for cover images and they're stricter than most authors expect.

Your cover needs to be at least 2,560 pixels on the longest side, with an ideal ratio of 1.6:1 (height to width). So a cover that's 2,560 x 1,600 pixels works well. If your cover is too small, too large, or the wrong ratio, KDP rejects it.

The other common issue is file format. Your cover needs to be a JPEG or TIFF - not a PNG, not a WebP, not a PDF. Some design tools export covers in formats KDP doesn't accept.

Check your cover dimensions in any image editor before uploading. If you designed it in Canva, make sure you're downloading the JPEG version at maximum quality.

Your Fonts Are Causing Problems

Embedded fonts cause more rejections than most authors realize. If you embedded a font that KDP doesn't support, or if the font file itself is corrupted, the whole upload fails.

Some authors embed decorative or custom fonts for style. The problem is that KDP needs to render your book on hundreds of different Kindle devices and apps, and custom fonts don't always translate reliably across all of them.

If your EPUB is getting rejected and you've embedded custom fonts, try stripping them out entirely and letting KDP use its default rendering. In most cases, books look cleaner with KDP's standard fonts anyway - Georgia for serif, a clean sans-serif for headings - and you eliminate an entire category of rejection risk.

If you want to keep custom fonts, make sure they're properly licensed for embedding and that they're referenced correctly in your OPF manifest. A font file that exists in your EPUB but isn't declared in the manifest will cause a validation error.

Your Metadata Doesn't Match Your Cover

This is the most common metadata mistake and it's easy to miss. Your title in the metadata field must match your title on the cover image exactly.

If your cover says The Blue House but your metadata title field says The Blue House: A Novel, KDP sees a mismatch and rejects it. Even an extra space, a missing subtitle, or different capitalization triggers a rejection.

So open your cover image and your metadata side by side. Copy the title from your cover exactly - character by character - and paste it into the metadata title field. Don't retype it. Copy and paste.

The same applies to your author name. If your cover says "J.K. Smith" but your metadata says "John K. Smith," that's a mismatch.

Your ISBN Is Wrong or Misformatted

If you assigned an ISBN to your ebook, it needs to be valid and correctly formatted. A real ISBN-13 has exactly 13 digits and starts with 978 or 979. Enter it without dashes or spaces.

If you bought your ISBN from a legitimate source like Bowker (US) or Nielsen (UK), enter it exactly as issued. If KDP assigned you a free ASIN instead, don't try to replace it with your own ISBN unless you know exactly what you're doing - mixing these up causes metadata conflicts.

If you're self-publishing an eBook without an ISBN, that's completely fine. Just make sure you select the correct option during setup rather than leaving the field blank when KDP expects an entry.

Your Images Are Broken Inside the File

Your book might look fine on your screen, but KDP reads the code underneath - and that code might be referencing images incorrectly.

Every image in your EPUB needs to be referenced correctly in the HTML content files and listed in the OPF manifest. If you moved an image after adding it, renamed it, or if the file path in your HTML is slightly wrong, KDP can't find it. The Kindle Previewer will show a blank box where your image should be - that's your clue.

Open your EPUB in Sigil and check the Book Browser panel. Every image file should appear there. Then open your HTML content files and verify that every <img> tag's src attribute points to the correct filename and path. Even a capital letter difference between Chapter1.jpg and chapter1.jpg will break the reference on case-sensitive systems.

Your Links Are Broken

Broken links inside your EPUB will get it rejected. This includes your table of contents links, internal chapter references, and any external URLs.

The most common broken link issue happens when you rearrange chapters after creating your TOC. If Chapter 5 links to an anchor that moved or no longer exists, that's a broken internal link. KDP's validator catches this.

Run your finished EPUB through EPUBCheck before uploading. It flags every broken reference -internal and external - with the exact file and line number where the problem is.

For external URLs (links to websites), make sure they're properly formatted with https:// and that they point to real, accessible URLs. A malformed URL in your text will cause a validation error.

Your Tables Are Breaking the Layout

Tables are particularly tricky in eBooks because eBooks reflow to fit different screen sizes. If your table uses fixed widths, merged cells, or complex layouts, it breaks on smaller screens and KDP's validator catches it.

Keep tables simple. Use percentage-based widths rather than fixed pixel widths. Avoid merged cells where possible. If your table is primarily for visual layout rather than data, consider converting it to plain text or a simple formatted list instead - it will render more reliably across all Kindle devices.

Special Characters Are Corrupting Your File

That fancy symbol you copied from a website or pasted from a PDF? It might not translate correctly to KDP's system.

Special characters, unusual punctuation, smart quotes that weren't properly encoded, or symbols from other languages can corrupt your file's encoding. The most common culprits are em dashes copied from Word that come through as strange symbols, curly quotes that weren't converted to proper UTF-8 encoding, and section symbols or other typographic characters from design software.

Run your EPUB through a validator and look for encoding errors. In Sigil, you can also do a Find & Replace across all files to locate and fix specific characters causing problems.

How to Catch All of This Before KDP Does

You don't have to wait for KDP to tell you something's wrong. Catching errors yourself first saves hours of re-uploading and waiting.

Step 1 - Run EPUBCheck

This is the same validator Apple Books, Google Play, and most major retailers use. Upload your file at check.w3.org/epub or run it locally. Fix every ERROR before doing anything else. WARNINGs are worth reviewing but won't necessarily cause rejection.

Step 2 - Open in Kindle Previewer

KDP's free Kindle Previewer shows you exactly what KDP sees. Check the navigation panel on the left for chapter entries. Flip through every page. Look for blank image boxes, broken layouts, or missing content. If it looks wrong in the previewer, it will look wrong on Kindle devices.

Step 3 - Check your metadata carefully

Before uploading, open your cover image and your metadata side by side. Verify the title, author name, and any series information match exactly.

Step 4 - Upload and watch the queue

After fixing everything and uploading, KDP usually processes your file within a few minutes. If it's rejected again quickly, something was missed. If it goes through to review, you fixed the issue.

If You've Fixed Everything and It's Still Rejecting

Sometimes corruption hides deep in the file's code and individual fixes don't resolve it. If you've addressed every visible error and KDP still rejects your EPUB, the fastest solution is rebuilding the file from scratch.

Go back to your source document - your Word file, your Scrivener project, whatever you wrote in - and do a fresh export. Don't try to fix the corrupted EPUB. Start clean.

This is annoying but it almost always works. A fresh export from a clean source document produces a structurally sound file without accumulated errors from previous edits and conversions.

Fix It Faster With Book Kraft AI

Book Kraft AI's EPUB Validator catches the most common rejection causes automatically - broken structure, missing manifest entries, font issues, and navigation errors - and explains each problem in plain language rather than technical error codes.

The Kindle Format Fixer also cleans up smart quote encoding issues, em dash problems, and special character errors that come through from Word and Google Docs exports.

Both tools are free to try at bookkraftai.com/tools/epub-validator, no login required.

The Short Version

KDP rejects EPUBs for technical reasons, not creative ones. Check your file structure, cover dimensions, fonts, metadata, images, links, and special characters. Run EPUB Check before uploading to anyone. Use the Kindle Previewer to catch visual problems. And if all else fails, rebuild from your source document.

The rejection is fixable. It almost always is.