EPUB → EPUB
Fix the title, author, language or publisher of an ebook without repacking it by hand. Every chapter, image and stylesheet is copied through untouched.
Drop your EPUB
or click to choose — the only ceiling is your own memory, none on our side
If your ebook library sorts a book under the wrong author, or shows a file name where a title should be, the cause is almost always the same: readers trust the Dublin Core fields inside the book's OPF file, and free ebooks are full of wrong, missing or placeholder values there. Renaming the file changes nothing, because no reader looks at the file name.
This edits the fields themselves. Drop the book in, its current title, author, language and publisher appear in the form, you change what is wrong, and you get the same book back with the metadata corrected — and with nothing else touched at all.
That last part is the design goal, and it is stricter than it sounds. The archive is rebuilt entry by entry: every chapter, image, font and stylesheet is copied across as the exact bytes it already was, only the OPF is replaced, and the mimetype entry is written first and left uncompressed as the specification requires. A converter that repacks the whole archive with default settings quietly compresses that entry and produces a file some readers reject — which is exactly the sort of breakage a metadata edit should never introduce.
Format by format
| What it does | EPUB | EPUB |
|---|---|---|
| Chapter files | The exact bytes you supplied | Copied across unchanged |
| Images, fonts, stylesheets | The exact bytes you supplied | Copied across unchanged |
| The OPF metadata block | Whatever the publisher left there | The values you typed |
| The mimetype entry | Stored first, uncompressed | Stored first, uncompressed |
| Entry count in the archive | However many there were | Exactly the same number |
| Reading order and table of contents | As published | As published |
What actually changes
This rewrites the Dublin Core fields inside the OPF and leaves every other byte of the archive alone. That is the whole point — nothing else can break, because nothing else is touched.
What survives
What does not
How it works
Its current metadata is read from the OPF and shown in the form.
Leave a field untouched and it stays exactly as it was.
Repacked entry by entry, with the mimetype stored first as the spec requires.
FAQ
Because readers trust dc:creator inside the book's OPF file over anything else, and free ebooks are full of wrong or empty values there. This edits the field the reader actually reads.
No. No mainstream reader uses the file name for anything but the file name. Apple Books, Calibre, Kobo and Kindle all read the OPF, which is why the fix has to happen inside the archive.
Not yet — cover replacement is its own tool and it is in the next batch. The current version deliberately touches only the Dublin Core text fields.
No. A DRM-protected file cannot be opened by this tool at all, and removing DRM is not something we support.
Yes, and more carefully than most tools manage. The archive is rebuilt with the mimetype entry stored uncompressed and first, no directory entries are added, and every other file is copied byte for byte — so the output has the same entry count as the input.
Title, author, language and publisher. Those are the four that libraries sort and display on. Leave any of them blank and the original value is kept.
Yes, though Calibre caches metadata in its own database when a book is added. Re-import the corrected file, or use Calibre's own “refresh from formats”, and it will pick the new values up.
DualBook reads the file you just corrected and returns it translated, with the metadata carried over.
