Extract text from a PDF
Save the text stored inside a PDF as a plain .txt file, and hear about it when there is none instead of getting an empty file.
How it works
A PDF does not contain a document in the sense a word processor does. It contains drawing instructions: set this font, move to this point on the page, draw the glyphs with these codes. There are no words, no lines, no paragraphs and no reading order anywhere in the file. What extraction actually does is read those instructions back and reconstruct the writing from the geometry. The only evidence is which glyph landed where, and how far apart.
Glyph codes and ToUnicode
The mapping from a glyph code to a character comes from the font's encoding and, where the producer supplied one, a ToUnicode table. Most PDFs carry that table and extract cleanly. A minority do not: an embedded subset font with a custom encoding and no ToUnicode entry gives the reader codes that mean something only to that one font program, and the output arrives as mojibake — plausible-looking runs of the wrong letters. That is a defect in how the PDF was written rather than in how it is being read, and no extractor can repair it.
A scan has no text layer
The larger problem is the one nobody states up front. A scanned document is a photograph of a page in PDF packaging. That covers anything that came out of a flatbed, a phone camera or a print-to-image workflow, and there is no text layer in it at all. Most free converters will process such a file happily and hand back an empty download with no explanation, which is how people end up concluding the tool is broken. This one checks: if the pages you selected yield almost nothing, it refuses and says why.
There is a test you can run yourself in any PDF viewer in about five seconds. Try to select a sentence with the cursor. If the words do not highlight, they are not words. What you need then is OCR, which recognises shapes in an image and is a fundamentally different operation from reading a value that is already stored.
Two columns read straight across
Even with a good text layer, layout is where extraction turns approximate. The file records positions, so a two-column article is two ribbons of text that happen to share a page and nothing in it marks where one ends. This tool buckets runs into lines by their baseline and sorts each line left to right, which means text sitting side by side at the same height is collected into one line read straight across the page: a two-column layout comes out interleaved, a line of the left column followed by a line of the right.
Separating them would take a page-wide gutter test, and the same test tears table rows into unrelated blocks, so it is left undone and named here instead. In reading order the tool then joins a line onto the one above when it does not end a sentence and sits one normal line advance below, which is what turns wrapped prose back into paragraphs. That rule is wrong for anything that is not prose: a table row does not end in a full stop, so at ordinary line spacing reading order glues each row to the one beneath and hands you a paste of numbers.
Preserve lines for tables
Switch line handling to preserve lines for tables, code listings, addresses, poetry or invoices, and every break the page drew is kept, one visual line per output line. Column separation still collapses to a single space, because the file records a gap measured in points and inventing tab stops from that would be a guess dressed up as data.
Reading rather than recognising
The distinction worth holding on to is that this reads rather than recognises. Where a text layer exists the output is exact — the characters the author typed, not a machine's best guess at them, with no confidence score and no accuracy rate to quote. Where it does not exist the output is nothing, and nothing is the truthful answer.
The failure modes are therefore the opposite of OCR's: extraction will never invent a word that was not there, but it will refuse outright on a scan, produce mojibake from a badly built font, and interleave headers and footnotes into the body when the producer stored them in an unhelpful sequence.
Which encrypted files still read
Encryption divides more finely than people expect. Most of what carries encryption at all is locked only against printing or editing, and a form or statement like that opens and reads normally, because no password is needed to decrypt it. Only a document that demands a password before it will open is refused, and there the refusal says so rather than handing you a blank file. All of it happens in this browser tab. The PDF is parsed here, the text is reassembled here, and the .txt is written to a blob URL that your browser downloads from itself.
Questions
Is my PDF uploaded?
No. The file is read into memory by this page, parsed by a WebAssembly build of pdf.js inside a Web Worker, and the resulting text is written straight to a download. Open the Network tab in developer tools before you start: you will see the code chunks the page needs to load and no request carrying your document. There is no server side to this tool to upload anything to.
It says there is no text to extract. What now?
Your PDF is a scan or an image-only export, so its pages are pictures rather than text. Open it in any viewer and try to drag-select a sentence. If nothing highlights, there is genuinely nothing in the file to extract. Recovering the words needs OCR, which reads shapes out of the image and returns a best guess with real error rates; that is a different operation and this tool does not pretend to do it. If the paper original is still to hand, most scanner software has a searchable PDF setting that runs OCR at scan time, and rescanning with it on beats running OCR after the fact.
Why are some characters wrong or unreadable?
The PDF's fonts are missing the table that maps glyph codes back to characters, so the codes are being read literally. Ligatures often survive this as one odd character where 'fi' or 'ffl' should be, and an entire document can come out as consistent nonsense when a subset font uses a private encoding. You can confirm the cause in seconds: select the same passage in a PDF viewer and paste it into a text editor. If the paste is equally garbled, the fault is in the file and every extractor will hit it.
Will tables and columns come out right?
Tables keep their rows if you set line handling to preserve lines, which is the setting to reach for; at ordinary line spacing reading order merges each row into the one above and the table becomes a paragraph of numbers. Columns do not survive either way. A cell boundary becomes a single space, because a PDF stores horizontal gaps in points rather than as a grid. Two-column pages come out interleaved for the same reason: text at the same height is read straight across, so you get a line of the left column, then a line of the right, alternating. Untangling that would need a gutter test that also splits table rows into unrelated blocks, which is the worse trade of the two. A reader that follows the document's tagged structure does better, but only where the tagging is correct. A minority of PDFs carry correct tagging, and nothing visible from outside the file tells you which ones.