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 answer is called the validation gap, and it's the single biggest reason indie authors hire professional formatters.

The Core Problem: Two Different Validation Standards

Here's what's happening behind the scenes:

Amazon KDP uses lenient validation. Amazon will accept your EPUB even if it breaks W3C standards. If there are errors, Amazon silently fixes them on its end.

Apple Books, Kobo, IngramSpark use strict validation. They run your EPUB through EPUBCheck, a tool that enforces W3C EPUB 3.0 standards strictly. No exceptions. No fixing broken files. Just rejection.

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:

"I could spend another 4 hours fixing XML markup, or I could pay a professional $49-150 to build this right from the start and guarantee it passes all platforms."

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

When you hire a professional who knows EPUB structure:

• They build the file to pass all platforms simultaneously (not just KDP)
• They validate before delivery (EPUBCheck = zero errors)
• You get files ready to upload to Apple, Kobo, IngramSpark, etc.
• No debugging. No rejections. No delays.

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.