There are two completely different kinds of PDF and they look identical on screen. One contains text — actual characters, with fonts and positions, which can be selected, searched, and copied. The other contains a picture of text, which cannot.
Almost every confusion about extracting text from PDFs comes from not knowing which one you have.
How to tell in five seconds
Open the file in any PDF reader and try to select a word with your cursor. If a selection highlight appears around the word, there is a text layer and extraction will be instant and exact. If the cursor draws a rectangle over the page like it would over a photograph, there is no text layer.
Digital PDFs — exported from Word, a browser, a design tool, an accounting system — always have a text layer. Scans do not, unless someone deliberately ran OCR on them afterwards. A document can also be mixed: a digital report with a scanned appendix, where half the pages give up their text and half do not.
Two different tools for the two cases
Reading an existing text layer and recognising text from an image are unrelated operations. The first is a lookup: the characters are in the file, and extraction reads them out. It is fast, exact, and cannot be wrong about what a character is.
The second is optical character recognition — inferring characters from pixels. It is slower, approximate, and depends on resolution and image quality.
Filum keeps these as separate tools deliberately, rather than hiding the boundary. PDF to Text reads the text layer and does no OCR. When you give it a pure scan it says so plainly and points you at OCR PDF, which reads text from the page image. What it will never do is hand you an empty file and call it a success — the silent empty download being the single most common failure of PDF text extractors.
What plain text keeps and what it discards
The output is the words. Line breaks come from the PDF's own layout, and pages follow one another in order separated by a blank line. Fonts, colours, columns, tables, and exact spacing are not preserved, because plain text has nowhere to put them.
That is the right output for a lot of jobs: feeding a document into a search index, quoting from it, counting words, moving text into another system, or checking what a file actually says. It is the wrong output if you want an editable document that keeps headings and bold — PDF to Word or PDF to Markdown are the tools for that.
One layout caveat worth knowing: text extraction follows the order the content was written into the PDF, which for a multi-column layout is not always the order you read it in. Columns can interleave. It is a property of the format rather than of any particular extractor.
Copying, limits, and errors that say something
Filum shows the extracted text on the page with a Copy button, alongside the page count and the exact character count read from the output itself — so if a document yields far less text than you expected, you can see that before downloading anything.
There is no fixed page or size limit. Pages are read one at a time and only the assembled text is held, so a long document costs little more than a short one; reading a text layer is dramatically cheaper than rendering pages to images.
When something is wrong you get a specific message rather than a generic failure: a password-protected PDF asks you to remove the password first, an unreadable one says it is not a valid PDF. And the whole thing runs inside your browser, on your own device — the file never leaves your computer.