What makes an EPUB pass validation
An EPUB is not a picture of a book. It is a small website in a zip file, built to a published specification — and stores check it against that specification with software before a human ever sees it.
The standard tool is epubcheck. Every major store runs it, or something built on it. It does not care whether your book is good. It cares whether the file is correct, and it reports what is wrong line by line.
"It opened on my laptop" is not evidence
This is the trap that catches almost everyone.
Reading apps are forgiving by design. Their job is to show the reader something rather than an error message, so they quietly patch broken markup, ignore a missing image, guess at a structure that was never declared, and carry on. Your book looks fine.
The store's checker has the opposite job. It is looking for reasons to reject, and it finds the things your reader app papered over. A file can open perfectly in three apps and still fail upload.
So opening it tells you the file is not catastrophically broken. It tells you nothing about whether it is valid.
What actually fails
The list is shorter than it feels, and most of it comes down to a few patterns.
Broken internal links and missing images. Something in the book points at a file that is not there, or is there under a different name. A reading app shows a gap. The checker calls it an error.
Files referenced but not packaged. Related, and just as common. An EPUB carries a manifest listing every file it contains. If the manifest and the actual contents disagree in either direction — a file listed but absent, or present but unlisted — that is a failure.
A table of contents that does not match the book. The navigation document has to reflect the real structure: the chapters that exist, in the order they exist, pointing at where they actually start. A contents page hand-typed as a list of styled paragraphs is not a table of contents. It is a page that looks like one.
Missing or invalid metadata. Every EPUB needs an identifier, a title and a language. Omit any of them and the file is invalid. Supply a malformed one — a language code that is not a real code, an identifier in the wrong form — and it is invalid in a way that is harder to spot.
Word processor markup. Exporting straight out of a word processor drags along nonstandard tags, dead style definitions and stray markup left over from tracked changes. Some of it is invalid outright; the rest makes the file fragile.
Fonts embedded without the right to embed them. A font on your computer is licensed for use on your computer. Embedding it in a file you distribute is a separate permission, and many licenses do not grant it. This one rarely trips the checker — it trips the store, or worse, the font's owner.
Images that blow the size limit. Stores cap total file size, and some price your book against it. Full-resolution photographs at print dimensions are the usual cause: an image shown 800 pixels wide does not need to ship at 4000.
The accessibility half
This used to be a nice-to-have. It is not any more — some markets now require it, and stores increasingly check for it and surface the result to readers.
A declared language. One line of metadata, and it decides how a screen reader pronounces every word in your book. Without it the reader guesses, often wrongly.
Real headings, in order. A chapter title has to be marked as a heading, not as a paragraph in a big bold font. Headings are what let someone jump between chapters instead of scrolling through the whole book. Skipping levels — a top-level heading followed by a third-level one — breaks the same navigation.
Alternative text on meaningful images. A short description of what the image conveys, for anyone who cannot see it. Decorative images should be marked as decorative so they are skipped rather than announced.
Accessibility metadata. A declaration of what the book provides: readable text, working navigation, how it handles images. Stores display this on the book's page, and readers with a print disability check it before buying.
None of this is charity. It is the same structural information the checker wants, written down where assistive technology can find it.
In the Interior Formatter. The EPUB 3 is built from the same manuscript as your print PDF, with accessibility metadata, language and ARIA roles set, and chapter numbering handled — it validates with zero errors and zero warnings under epubcheck. Start a book → · about the Interior Formatter
Structure first, and the rest follows
Here is the rule that makes all of the above stop being a checklist.
Mark up what things are, not what they should look like. A chapter title is a heading. A chapter break is a break in the document, not four empty paragraphs. An emphasis is emphasis, not italic text. A scene break is a marked division, not a row of asterisks you typed and centered by hand.
Manual formatting hacks are the root of nearly every failure on this page. Spaces used as indents, returns used as spacing, bold used as hierarchy, a hand-built contents page used as navigation — each looks right in a word processor and carries no structure into the file. The checker sees a book with no chapters.
Get the structure right and validation stops being a step you pass. It becomes a side effect of a book that was built correctly, and the accessibility half comes almost free, because it was the same information all along.
In the Interior Formatter. One manuscript in, a print PDF and a valid EPUB 3 out — with an optional table of contents generated from your real chapter structure rather than a page you typed. Start a book → · about the Interior Formatter
Make yours
Everything here is built into the tools, and they are free to use: name your book, bring your manuscript or your artwork, and work as long as you like. You only pay when you want the files without the preview watermark.
Back to: Ebook cover size · More: EPUB vs print PDF · How to format a book interior · Front matter order