PDF does not store a document
This is the fact everything else follows from, and almost nobody is told it.
A Word file stores a document model: this is a heading, this is a paragraph, this is a table with three columns, these are in this order. A PDF stores instructions for painting a page: put this glyph at this coordinate, in this font, at this size. Then the next glyph, at the next coordinate.
There are no paragraphs in a PDF. No headings, no lists, no reading order. What looks like a heading is text that happens to be larger and higher up. What looks like a table is a set of lines and some text positioned between them. The structure exists in your eyes, reconstructed from the layout, and it was thrown away when the file was written.
Conversion therefore is not a translation between two formats holding the same information. It is an attempt to infer a document model that is not there.
What that means for the output
Text comes back. Words, in the order the producer drew them, grouped into lines. For a straightforward single-column report that is most of what you wanted, and the result is genuinely usable.
What does not come back is anything structural. Headings arrive as ordinary paragraphs that happen to be short. Bulleted lists arrive as paragraphs beginning with a bullet character. Tables arrive as runs of text, because the lines that made them a table were drawings rather than a table. Columns interleave if the producer drew them line by line across the page rather than column by column. Images, styling and precise layout do not survive at all.
The [msm_tool slug="pdf-to-word"] is explicit that it extracts the text layer into an editable document rather than reproducing the original. That is the honest description of what any converter is doing; the ones promising a perfect visual match are either doing heavy layout guesswork that fails unpredictably, or embedding pictures of your pages in a Word file, which is editable in name only.
The two documents it cannot convert
Scanned PDFs. A scan is a photograph. There are no characters to extract, only an image, and converting it needs optical character recognition — a genuinely different technology that reads shapes and guesses at letters, with an error rate that depends on scan quality. A converter that has no OCR should say so rather than return an empty document.
Subset fonts with no Unicode map. This one is obscure and worth knowing because it looks like corruption. To save space, producers often embed only the glyphs a document actually uses, under a private encoding of their own. If the producer also wrote a ToUnicode map, the characters can be read back. If it did not, the file knows how to draw the text but nothing in it says which letters those shapes are. Extraction then yields gibberish, and reporting the failure is better than emitting the gibberish.
Ask for the source first
The most reliable conversion is not doing one. A PDF was exported from something — a Word file, a design document, a spreadsheet, a system that generated it. That original still has the structure the PDF discarded.
Thirty seconds asking whoever sent it beats an hour rebuilding a table by hand. This sounds obvious and it is skipped constantly, because converting feels like the self-sufficient option and asking feels like an imposition. It is not.
When conversion is the right call
When the source genuinely does not exist — an old document, an external party, a system nobody maintains. When you need the words rather than the document: quoting, translating, searching, feeding into something else. When the document is mostly flowing prose, which is where inference works best.
It is the wrong call when the layout is the content. Forms, invoices, financial tables, anything typeset with care. For those, extract the text to save the retyping and rebuild the structure deliberately, rather than trying to fix a mangled approximation of it — cleaning up a badly converted table takes longer than making a new one.
What to check afterwards
Read the beginning and the end of the output, and count the pages against the original. Text that stops early is the classic symptom of an extraction problem, and it is easy to miss because what did come through looks perfectly fine.
Then check anywhere numbers matter. Figures inside tables are where interleaving does its damage, and a column that has been read across rather than down produces numbers that are individually correct and collectively meaningless. Nothing about the output will look wrong. That is exactly why it is worth checking.