Klein argues that although EPUB is an open W3C standard with many rendering engines, epubcheck is the only validator anyone uses, and its Adobe-seeded rule set encodes Adobe Digital Editions' rendering quirks rather than the actual spec. Because Kobo treats epubcheck warnings as fatal at upload, a single implementation effectively dictates what counts as a 'valid' ePub across the industry.
Klein documents that his files open cleanly in Apple Books, Calibre, Thorium, Kobo devices, and even Kobo's own desktop app — they fail only at Kobo Writing Life's upload check. He frames this as a process bug: Kobo has chosen to escalate non-fatal epubcheck warnings into hard rejections, blocking publication of files that demonstrably render correctly everywhere else.
Klein provides diffs and rule IDs showing epubcheck flagging valid CSS3 properties, SVG constructs explicitly permitted by EPUB 3, and font subsetting techniques used by every Big Five publisher. He points to GitHub issues — some six years old, some closed as 'won't fix' or 'works as intended' without explanation — to argue the validator is not just out of date but actively unmaintained against the spec it claims to enforce.
André Klein, an indie author and ePub tooling hobbyist, published a post titled "Your ePub Is fine. Kobo disagrees. Blame Adobe." It hit 778 on Hacker News, which is roughly the threshold where a niche publishing-pipeline gripe stops being niche.
Klein's complaint is narrow and specific. He uploads ePub files to Kobo Writing Life. Kobo's ingest pipeline runs them through epubcheck — the validator originally written by Adobe and the IDPF, now nominally maintained by the W3C — and rejects files for warnings that have nothing to do with whether the book renders. His files open cleanly in Apple Books, Calibre, Thorium, every Kobo device he owns, and the Kobo desktop app itself. They fail Kobo's *upload* check because epubcheck emits a warning, and Kobo's pipeline treats warnings as fatal.
The specific failures Klein documents are the kind that should embarrass any validator: complaints about CSS properties that are valid CSS3, complaints about SVG constructs that the EPUB 3 spec explicitly permits, and complaints about font subsetting techniques that every commercial ePub from the Big Five publishers uses. He includes diffs. He includes the exact epubcheck rule IDs. He links the open GitHub issues — some of them six years old, some marked "won't fix," some marked "works as intended" with no further explanation.
The story is not really about Kobo, and it's not really about Adobe. It's about what happens when a single closed-source-adjacent implementation becomes the reference for an open standard.
EPUB is an open standard. It's maintained by the W3C now, after the IDPF folded into it in 2017. The spec is public, the test suites are public, and there are at least a dozen rendering engines in the wild. But there is exactly one validator anyone uses: epubcheck. Adobe wrote the original. Adobe seeded the rule set. And although the W3C technically owns it now, the rules encode a decade-plus of Adobe Digital Editions' rendering quirks as if they were the specification itself. When a validator's bugs become indistinguishable from the spec, the spec stops being the contract — the validator is.
This is the same pattern that broke HTML for fifteen years. IE6's quirks became the de facto standard because every site shipped to it. The W3C's HTML spec said one thing; the deployed renderer said another; developers wrote to the renderer. The difference here is that publishing has no Firefox moment, no Chrome reset. There is no competing validator with enough adoption to force the rules back toward the actual standard. Kobo, Apple, Google Play Books, Barnes & Noble — all of them gate uploads on epubcheck. So do most aggregators. So does Draft2Digital. So does IngramSpark.
The Hacker News thread surfaced several flavors of the same pain. A professional typesetter described shipping the same file to five stores and getting five different combinations of pass/fail because each store runs a different epubcheck *version*. A small press described maintaining a private fork of epubcheck just to suppress warnings their books trigger but their readers don't care about. A former Adobe engineer (unverified, but cited in-thread) said the rule set was originally tuned to match Adobe Digital Editions' rendering, not the spec, because ADE was the test target the team had.
The deeper problem is that epubcheck has no real funding. The W3C Publishing Working Group maintains it on volunteer hours. Adobe's involvement has dwindled. The result is a validator that nobody owns, everyone depends on, and that quietly defines what "valid EPUB" means for every commercial distribution channel. That's a supply-chain failure dressed up as a standards story.
If you ship anything that has to pass a third-party validator you don't control — and that's most of us — Klein's post is a useful reminder to audit the gap between your spec and your gatekeeper. The spec is what you can argue you implemented. The gatekeeper is what actually decides whether your artifact ships.
A few concrete moves worth borrowing from the publishing pipeline pain:
First, pin the validator version in your CI, the same way you pin compiler versions. Klein's story is partly about Kobo silently bumping epubcheck and breaking previously-accepted files. If your CDN, payment processor, app store, or package registry runs a validator, find out which version, find out their update cadence, and run that exact version locally before you ship. Don't run "latest" against a gatekeeper that pins to a specific tag.
Second, treat "warnings as errors" as a deployment policy decision, not a default. Kobo's pipeline rejects on warnings. epubcheck emits warnings for spec-compliant constructs. The combination is fatal even when neither part is wrong in isolation. If you run linters or validators in your release pipeline, decide explicitly which severity levels block a release and document why. "We treat warnings as errors because that's what the tool defaults to" is how you ship policy by accident.
Third, don't let the bug tracker become the spec. If you're depending on an open standard, read the actual standard before you read the validator's source. Klein only figured out his files were valid by reading EPUB 3.3 directly and finding that the constructs epubcheck flagged were explicitly permitted. The standard is the contract; the tool is an implementation.
The Kobo-epubcheck-Adobe loop will not get fixed. There is no commercial incentive for any single party to fund a validator rewrite, no competing implementation with enough credibility to displace the incumbent, and no W3C process likely to move fast enough to matter. What's worth watching is whether someone ships an open-source pre-flight tool that diffs your ePub against multiple validators and tells you which warnings each store will actually reject on — the publishing-pipeline equivalent of caniuse.com. That's the missing layer, and the kind of thing a weekend project could become essential infrastructure for.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.