A PDF stores glyphs at positions, not sentences

That single fact predicts everything about how extraction behaves. A PDF records instructions to draw particular characters at particular coordinates. There is no paragraph, no reading order, and frequently no stored word boundary at all — the space between two words may be nothing more than a gap in x-coordinates.

So extraction is reconstruction. It has to infer structure that was never written down, by grouping characters that sit close together into lines and lines into blocks.

Which PDFs come out cleanly, and which do not

Because it is inference, you can predict the result before you try:

• Single-column body text from a word processor extracts almost perfectly.
• Two columns often interleave, because reading order has to be guessed from position and the guess can zig-zag across the gutter.
• Tables lose their structure — a table in a PDF is text at coordinates with no grid recorded anywhere.
• Headers, footers and page numbers land inline in the middle of the text, since nothing marks them as furniture.
• Ligatures and unusual fonts can produce odd or missing characters, because the mapping from glyph back to character is not always present in the file.
• Hyphenated words broken across a line stay broken.

None of these are failures of the extractor. They are the cost of a format that was designed to be printed rather than read by a machine.

The scanned PDF, which is the usual disappointment

A scanned document contains an image of text. There is no text in the file, so extraction returns nothing or almost nothing, and no extractor can do better — there is nothing there to find.

This tool does not perform OCR. Recognising characters in a picture is a different problem needing a different kind of tool.

The quick test takes five seconds: open the PDF in any viewer and try to select a line of text with your cursor. If you cannot select it, no extractor will find it. That check saves a great deal of confusion about whether a tool is broken.

What extraction is genuinely good for

Getting quotable text out of a report. Searching a document that is awkward to search in a viewer. Feeding content into something that only accepts plain text. Getting a word count of the actual prose rather than the layout.

Output is available as plain text, Markdown with headings inferred, or HTML — and multiple files can be processed at once, with the results downloadable individually or together as a zip.

Working with imperfect output

Expect to fix joins, and know where to look: the start and end of each page is where furniture and column errors cluster, because that is where headers, footers and column breaks live. Reading the seams rather than the whole document catches most of what went wrong.

Everything runs in your browser and no file is uploaded. If you want the formatting attempted rather than discarded, PDF to Word tries to preserve some structure — which means it has correspondingly more to get wrong, where plain text discards it all deliberately and predictably.