OEB to TXT
Nothing in that folder leaves your browser, and nothing is downloaded to make it work — not a library, not a reader, nothing. The files are read where they sit and the book is built in the page.
One thing to know before you choose: this takes a folder rather than a file. Dragging the folder onto this page works in any browser that can do it at all; the button needs Safari 18.4 on iPhone, Chrome 132 or Firefox 142 on Android, or any desktop browser. Older ones will quietly hand back a file instead, and this page will say so rather than pretending the folder was empty.
The words, in reading order, and nothing else.
The chapters in spine order with the markup taken off. Pictures go, because plain text has nowhere to put one; what was there is listed in the report rather than silently dropped.
How this works, and why nothing is fetched
Your browser hands the page the files in the folder, with
their paths. Everything after that is reading bytes: an EPUB is a ZIP, and
CompressionStream does the deflating natively. The one thing
worth saying twice is about the pictures. Everywhere else on this site an
<img src="dot.png"> in a file you upload points at
something the page has never seen, and going to get it would mean
contacting another computer. In a folder the picture is right
there, handed over with everything else — so it goes into
the book, and nothing is fetched to do it.
Why this one takes a folder
An Open eBook is not a file. The extension is
.opf and that file is a manifest: a list of the
XHTML and images that sit beside it, with a spine saying what order to
read them in. On its own it contains no text at all. calibre's own Open
eBook output writes a directory rather than a file for the same reason.
So a page that takes one file could not convert one, however good its
reader was.
Which browsers can hand over a folder
Read from MDN's browser compatibility data rather than assumed, because the obvious test for this is wrong:
| Desktop | Chrome, Edge, Firefox and Safari, for years |
|---|---|
| Safari on iPhone | 18.4 and later |
| Chrome on Android | 132 and later |
| Firefox on Android | 142 and later |
The reason this is spelled out rather than detected:
setting webkitdirectory on an input and reading it back
returns true on browsers where choosing a folder does nothing
whatever. On iOS before 18.4 the property “can be set but has no
effect”; on Chrome for Android before 131 it “reflects the
attribute, but users cannot choose a directory”. A check that
answers yes when the answer is no is worse than no check, so this page
does not pretend to have one — it tells you what works, and if your
browser hands back a file instead of a folder it says exactly that.
What it will not do
- It will not go and get anything. A picture at a web address stays a web address, and is counted in the report rather than fetched.
- It will not read a folder you have not handed it. Nothing here asks for standing permission to your disk — the files are read once and kept nowhere.
- It stops at 5,000 files or 400 MB, and says so instead of struggling.