Your ePub Is Fine: Kobo, Adobe, and the eBook Validation Wars

If you've ever uploaded a perfectly valid ePub file to Kobo only to have it rejected with cryptic error messages, you're not alone. A viral post climbing to over 800 upvotes on Hacker News today captures a frustrating reality for independent authors and developers: your ePub is probably fine. Kobo just disagrees—and Adobe is the reason why.

The Problem: Valid Isn't Good Enough

The ePub format is an open standard maintained by the W3C. You can validate your ePub files using tools like EPUBCheck, the official validator that ensures compliance with the EPUB 3 specification. When your file passes EPUBCheck, you should be good to go, right?

Not if you're publishing to Kobo.

Andre Klein's article documents a common scenario: authors create ePub files that pass all official validation checks, only to have Kobo's upload system reject them with vague errors. The files work fine in Apple Books, Google Play Books, and other readers. They're valid according to the spec. But Kobo says no.

The culprit? Adobe's Digital Editions validation layer, which Kobo uses as part of their ingestion pipeline. Adobe has effectively created a proprietary validation layer on top of the open ePub standard, and major platforms have adopted it as a gatekeeper.

Adobe's Shadow Standard

Adobe Digital Editions (ADE) was originally designed as an eBook reader and DRM management system. Over time, it became the de facto validation tool for major eBook retailers, including Kobo. The problem is that ADE enforces rules that go beyond—or sometimes contradict—the official ePub specification.

Common issues include:

  • Overly strict CSS parsing: Adobe's validator flags valid CSS properties that it doesn't recognize, even if they're part of standard web specs
  • Metadata requirements: ADE demands certain metadata fields that aren't required by the ePub spec
  • File structure pickiness: Valid but unconventional directory structures can trigger rejections
  • SVG and image handling: Adobe's renderer has quirks that become validation requirements

The result is a fragmented ecosystem where "valid ePub" has two meanings: spec-compliant, and Adobe-compliant. For developers and authors targeting multiple platforms, this means extra testing, extra debugging, and often, manual workarounds for a single platform.

Why This Matters for Developers

If you're building ePub generation tools, publishing pipelines, or working with digital content workflows, the Kobo-Adobe situation is a microcosm of a larger problem: proprietary validation layers that sit on top of open standards.

This pattern shows up everywhere:

  • Web standards: Browsers implementing their own quirks on top of W3C specs
  • API specs: Vendors claiming OpenAPI compliance while requiring undocumented vendor extensions
  • Data formats: "Industry standard" tools that add proprietary validation rules to open formats

The ePub case is particularly egregious because the format was explicitly designed to be open and interoperable. The entire point was to escape vendor lock-in. When a DRM vendor becomes the de facto validation authority, we've come full circle.

The Workaround Landscape

Developers and authors have found various workarounds:

  1. Use Adobe's tools: Validate with Adobe Digital Editions before uploading to Kobo, even though it's not the official validator
  2. Simplify everything: Strip out any CSS or features that might confuse Adobe's parser
  3. Test on physical devices: Adobe's validator behavior sometimes differs from what actually renders
  4. Use platform-specific builds: Maintain separate ePub builds for different retailers

None of these are satisfying solutions. They all involve extra work to comply with an unofficial, undocumented standard.

What Needs to Change

The broader developer community should push back on this pattern:

  • Platforms should validate against official specs: If Kobo wants to reject files, they should reference specific violations of the ePub 3 spec, not Adobe's proprietary rules
  • Validation tools should be transparent: Adobe should document exactly what rules they enforce beyond the spec, or platforms should stop using ADE as a gatekeeper
  • Open standards need teeth: The W3C and IDPF (now part of W3C) should be more aggressive about calling out platforms that break interoperability promises

For individual developers, the lesson is clear: when building tools that generate or validate open formats, always test against real-world platforms, not just the spec. Your valid output might not be "valid enough" for the gatekeepers.

The Takeaway

The ePub validation mess is a reminder that open standards are only as open as the ecosystem allows them to be. When a single vendor's DRM implementation becomes a de facto validation layer, we lose the interoperability benefits that open formats are supposed to provide.

If you're building ePub tools or publishing workflows, budget time for Adobe-specific quirks. If you're an indie author, know that validation errors from Kobo often reflect Adobe's opinions, not actual spec violations. And if you're in a position to influence platform decisions, push for validation against official specs, not proprietary parsers.

Your ePub is probably fine. The ecosystem is what's broken.