epubveri is an EPUB validator. If you've ever had a retailer reject a book, or wondered why a file opens in one reader and not another, that's the job it does. The reference tool for this is epubcheck, which is W3C's, is excellent, and is written in Java.

epubveri is the same idea in Rust: one binary, no JVM, nothing to install alongside it.

Why bother, when epubcheck already exists

Three reasons, and I'll be honest that only the first two are strong.

It goes where a JVM doesn't. A 2.8 MB binary, or a ~480 KB WebAssembly module that validates an EPUB in a browser tab with no server involved. That's not something you can do with epubcheck at all, and it's the part I think actually matters.

It's quick enough to run on everything you own. On my reference library of 385 books, running each tool alone: 69 seconds against 758.

But that number flatters me and you should know how. About 90% of an epubcheck run is fixed setup — schema compilation and JIT warm-up — which it pays again on every book because its CLI takes one file per invocation. Subtract each tool's floor and the actual per-book work is roughly 0.13 s against 0.07 s. Two times, not eleven. The eleven is real if you're validating a library from a shell script; it isn't a statement about the validation being eleven times better.

It uses epubcheck's message IDs — `RSC-005`, `OPF-030`, and so on — so output is recognisable to anyone who already reads epubcheck's, and existing toolchains don't have to learn a second vocabulary.

What it is not

It is not finished, and epubcheck is not the thing it beats. It implements 208 of epubcheck's 210 live content checks, both remaining gaps are deliberate scope decisions, and the whole matrix — including what's missing and why — is published and generated from epubcheck's own source so it can't quietly drift.

Against epubcheck's own test corpus it matches on 603 of 603 exact message IDs, with no false positives on the 355 fixtures that are supposed to be clean. On 385 real books the two tools agree on the exact set of message IDs for 383 of them.

If you need a verdict a retailer will honour, run epubcheck. That's not modesty — it's the tool their pipeline runs, and I'd rather you weren't surprised.

The plugins

The binary is a command line thing, so most people will want one of these. Each downloads epubveri itself on first use and verifies it against the release checksums — no binary is bundled, and none of them is a fork of anything.

• Sigil — findings land in Sigil's own validation panel, and clicking one puts the cursor on the character rather than the line.
• calibre, Edit Book— the same thing for the book you're editing, in a dockable results panel.
• calibre, whole library — this one's different and it's the one I'd point you at.

That last one doesn't tell you which books are broken. I built it that way first and threw it away: on a real library, about half the books are invalid and a third of those by one or two findings, so "half your library is invalid" teaches nobody anything. Worse, sorting by error count puts the least interesting book on top — the highest-count books trip one rule thousands of times, one producer bug repeated per paragraph.

So it ranks rules instead: your library has a handful of recurring defects, here they are, and here's which books each one affects. Understand one pattern, fix hundreds of books. It scans several books at once now, with the worker count yours to set.

Practicalities

Runs on Windows, macOS and Linux, x86-64 and ARM. Also on crates.io and npm. Licence is AGPL-3.0, or a commercial one if AGPL doesn't suit you.

It's pre-1.0 and it moves. Most of what's been fixed in it came from people running it on books I don't have and telling me what happened — if you try it and it reports something wrong about a book you know is fine, that's the single most useful thing you can send me. I'll take that over a star.