EPUB Validator
Client-side · No upload · No account
“This book could not be opened” is the same message whatever went wrong, which is why it is useless. Drop the file in and find out which of the five structures a reader needs is actually broken — and whether it is something you can fix or a copy you need to replace.
Drop the EPUB that won't open
The container, package document, manifest and spine are checked in your browser — no upload, no server, nothing stored.
The five things a reader needs
1. A readable ZIP. An EPUB is a renamed ZIP archive, and a reader starts by reading the directory at the end of it. A truncated download fails here, before anything about the book is even looked at.
2. META-INF/container.xml. This one small file says where the book proper starts. A .cbz comic archive or a zipped folder of HTML is a perfectly valid ZIP with no container, which is why those open nowhere.
3. A well-formed package document. The .opf file holds the metadata, the manifest and the spine. It is XML, so a single unescaped ampersand in a title breaks the entire book — the most common self-inflicted failure by a distance.
4. A manifest that resolves. Every file listed must exist in the archive, spelled identically, case included. This is what breaks books that worked fine on the machine that built them.
5. A spine that points at real documents. The spine is the reading order. If it is empty, or references manifest ids that do not exist, there is nothing to open even when every file is present.
A structurally perfect book can still refuse to open if it is DRM-locked — that is valid structure a reader is not permitted to decrypt. If everything here passes, read how to check if an EPUB has DRM next.
Questions
Is this the same as EPUBCheck?
No, and deliberately. EPUBCheck validates every content document against the full specification and reports hundreds of advisory messages, most of which no reader cares about. This checks the handful of structures that actually stop a book from opening — the archive, container.xml, the package document, the manifest and the spine — in the order a reader hits them.
It says my archive can't be read.
The ZIP directory at the end of the file is unreadable, which nearly always means the download was interrupted or the file was truncated in transfer. Compare the file size against the source if you can, then download it again. No repair tool can invent the missing bytes.
What does "manifest files missing from the archive" mean?
The package document lists every file the book uses, and one or more of them are not in the ZIP. The usual cause is case: inside a ZIP, Image.jpg and image.jpg are different files, so a book built on Windows or macOS — where the filesystem ignores case — breaks the moment a reader looks the file up exactly as listed. Fixing means correcting either the href in the package document or the filename in the archive so the two match.
Everything passes but my reader still refuses the book.
Then the structure is sound and the problem is elsewhere: DRM (which is valid structure the reader cannot decrypt), a file above the app's size limit, or a reader that doesn't support a feature the book uses, like fixed layout. The DRM checker covers the first two.
Can this repair the file?
No. It tells you what is wrong and where. Missing metadata can be filled in with the metadata editor; a bad mimetype entry is fixed by re-zipping; missing files and a broken spine need the source of the book, because the content genuinely is not there.
Is the file uploaded?
No. It is read with JavaScript in your browser tab and never leaves your device. Turn the network off after the page loads and it still works.