Why Your EPUB Passes Amazon But Apple Rejects It (The Validation Gap)

This is the most frustrating moment in indie publishing.

You spent weeks formatting your book. You tested it in Kindle Previewer. It looks perfect. You upload to Amazon KDP. Accepted. You feel relieved.

Then you decide to publish wide—upload the same EPUB to Apple Books, Kobo, IngramSpark. And you get rejected.

"Your file contains validation errors and cannot be uploaded."

Same EPUB file. Amazon accepted it. Apple rejected it. Why?

The difference is often described as a validation gap: retailers use different conversion, inspection and reporting pipelines, so they can produce different outcomes from the same source file.

The Core Problem: Different Retailer Pipelines

Here's what's happening behind the scenes:

Amazon, Apple, Kobo and aggregators do not process every file identically. They may convert, inspect and report the same underlying problem differently. A successful Amazon upload therefore does not certify the original EPUB for every other destination.

This is why the same file passes KDP but fails everywhere else. You're literally uploading to retailers with completely different validation rules.

How Amazon's Validation Works (Loosely)

When you upload to KDP, Amazon's system checks for a few basic things:

• File integrity: Is the EPUB a valid ZIP file?
• Content policy: Does the book contain prohibited content?
• Basic structure: Does it have chapters? Does it have a cover?
• Metadata: Does it have a title and author name?

What Amazon does NOT check: Whether your EPUB strictly follows the W3C EPUB 3.0 specification. Amazon doesn't care if your markup is technically invalid. Amazon doesn't validate your internal links. Amazon doesn't care if your manifest is missing declarations.

This is remarkably forgiving. You can publish an EPUB with:

• Broken internal links
• Invalid HTML markup
• Missing anchor IDs
• Incorrect ZIP structure

...and Amazon will accept it. Amazon will even convert and fix many issues on its end so readers see a working book.

How Apple Books Validation Works (Strictly)

Apple Books takes a fundamentally different approach. They run your EPUB through EPUBCheck—a strict validator that enforces the W3C EPUB 3.0 specification to the letter.

EPUBCheck looks for:

• Valid XHTML markup: Every tag must be properly opened and closed
• Valid XML structure: All special characters must be encoded correctly
• Proper manifest declarations: Every file type must be declared in the manifest
• Valid internal links: Every link must point to an anchor that actually exists
• Correct file structure: The mimetype file must be first and uncompressed
• Proper metadata: All required metadata must be present and valid

If your EPUB fails ANY of these checks, Apple rejects it. No mercy. No "we'll try to fix it." Just rejection.

Kobo, IngramSpark, Google Play Books, and every other strict platform use the same EPUBCheck validator. So if Apple rejects it, they will too.

Why Does This Validation Gap Exist?

Amazon's philosophy: "We care about the reading experience. If your file has errors, we'll silently fix them so readers see a beautiful book. The technical correctness of your file doesn't matter—the book in the reader's hand is all that matters."

Apple's philosophy: "We care about standards compliance. Your file must be technically correct according to the EPUB spec. We're not going to patch your files. If they're broken, they're rejected."

Both philosophies are valid. But the practical result is:

The same EPUB file can pass Amazon and fail Apple Books, Kobo, IngramSpark, and every other strict platform.

Real Example: The Broken Table of Contents

Here's what actually happens:

You create your EPUB in Microsoft Word. You set up a table of contents with clickable chapter links. You test it in Kindle Previewer—everything looks perfect.

You upload to KDP. Accepted immediately.

You upload to Apple Books. Hours later, you get the rejection email with an error: "RSC-012: Fragment identifier is not defined."

What happened?

One of your TOC links points to Chapter 5, but when Word converted your document to EPUB, it gave Chapter 5 a different ID than what the TOC expected. The TOC link says "go to #chapter-05" but the actual chapter heading has ID "Chapter_5"—mismatch.

Amazon doesn't check for this mismatch. Amazon just converts the whole thing and makes it work anyway.

Apple's validator checks for this. It finds the broken link. It rejects the file.

To fix this, you'd need to:

1. Unzip the EPUB file
2. Find which file contains the broken link
3. Open that XHTML file in a text editor
4. Find the exact link and ID mismatch
5. Fix it by hand (change the link OR change the ID to match)
6. Re-zip the EPUB correctly (with mimetype first, uncompressed)
7. Validate again with EPUBCheck to confirm it's fixed
8. If there are more errors, repeat

This process takes 2-4 hours if you know what you're doing. For most authors, it takes a full day or more.

The DIY Debugging Path (If You Want to Try)

If you're determined to fix validation errors yourself:

1. Download EPUBCheck (free, from the IDPF)
2. Run your EPUB through EPUBCheck — It will output a list of all errors
3. For each error: Look up what it means, find the problematic file, edit it, re-zip
4. Validate again until you get zero errors
5. Upload to Apple Books and hope it passes

Most EPUBs have 5-20+ errors. Each error requires understanding EPUB structure, XML markup, and how the OPF manifest works.

The time investment is substantial. And if you make one typo when editing the XML, the entire file breaks and you have to start debugging again.

Why Most Authors Just Hire Someone

After spending 2-4 hours debugging their EPUB, most authors realize:

You can spend more time diagnosing the package yourself, or pay a professional to rebuild and check the EPUB before you upload it.

That's the inflection point where hiring a formatter makes financial sense.

When you hire a professional who knows EPUB structure:

• They build a standards-based file intended for the retailers you plan to use
• They validate before delivery (EPUBCheck = zero errors)
• You get files ready to upload to Apple, Kobo, IngramSpark, etc.
• Fewer avoidable file problems before upload

What a Professional Does Differently

I build EPUBs with all platforms in mind simultaneously. From the moment I start formatting:

• I use valid XHTML markup
• I create a proper manifest with all file types declared
• I set up internal links with matching anchor IDs
• I ensure W3C EPUB 3.0 compliance
• I validate with EPUBCheck before delivery

The result: An EPUB that passes EPUBCheck on the first try and uploads successfully to Amazon, Apple Books, Kobo, IngramSpark, Google Play Books—everywhere.

The Bottom Line

Amazon's lenient validation is convenient—until you try to go wide.

The moment you upload to Apple Books or Kobo, you hit a wall. The file that worked fine on KDP fails validation. And now you're stuck debugging XML markup or uploading a rejected file.

The best solution isn't debugging your EPUB after the fact. It's building it correctly from the start.

If you're planning to publish on multiple platforms, build your EPUB to pass strict validation from day one. You'll save time, eliminate rejections, and avoid upload delays.

That's what professional formatting gives you—one file that works everywhere.