You convert a PDF to Word, open it, and the words are all there. Then you start editing and it fights you: a heading that will not take a heading style, a paragraph that breaks in an odd place, spacing that shifts when you add a sentence.
The text came back perfectly. The document did not, and the difference between those two things is the whole subject.
What a PDF stores, and what it does not
A PDF is a description of a finished page. It says: place this character at this coordinate, in this font, at this size. Repeat a few thousand times. That is a complete and exact record of how the page looks, and it is the reason a PDF renders identically everywhere — which is the entire point of the format.
What it does not record is why. Nothing in the file says that the line at the top is a heading, that these forty lines form one paragraph, that this block is a list, or that those cells are a table. A human reads a bigger, bolder line and understands “heading”. The file contains bigger, bolder characters at coordinates.
A Word document is the opposite kind of thing. It stores intent — this is a Heading 1, this is a paragraph, this is a table — and works out the appearance when it displays. Converting between them means inferring everything the PDF threw away.
The measurement: all the words, none of the structure
We put a two-page agreement through PDF to Word and read the result’s own XML rather than trusting how it looked.
- 270 of 270 words recovered — 100%. Not one character lost.
- 18 paragraphs reconstructed from the spacing between lines.
- 0 headings detected. The document had several, visibly bolder and larger. Every one arrived as an ordinary paragraph that happens to be bold.
That is the shape of the problem in one result, and it is the figure above. Text extraction is close to solved. Structure recovery is a guess, and the guess is conservative — a converter that confidently marked the wrong lines as headings would produce a document that is worse to work with than one with none.
Practically: your words will be there. Your outline, your navigation pane and your automatic table of contents will not.
Fonts are the other half
The second thing people notice is spacing that is subtly wrong — a line that wraps one word early, a page that gains a line.
PDFs usually embed their fonts, often as a subset containing only the characters the document actually uses. That is efficient and it is excellent for display, but a subset is not an installable font. The converter has to choose a font on your machine that is close, and close is not identical: every glyph is a fraction of a point wider or narrower, and across a paragraph those fractions accumulate into a different line break.
Nothing is broken when this happens. Two different fonts simply cannot occupy the same space.
What converts well, and what does not
Converts well: continuous prose, single-column layouts, simple ruled tables, documents that began life in a word processor. The more the page looks like a letter, the better the result.
Converts badly: multi-column layouts, where reading order has to be inferred and can snake across columns. Text in boxes or sidebars, which may land anywhere in the flow. Figures with captions positioned around them. Anything where a human uses layout to signal reading order, because that signal was never written down.
Does not convert at all: a scanned page, which contains no text to recover. It needs OCR first, and then you are editing a recognition of the text rather than the text.
The direction that is reliable
Worth saying plainly: converting to PDF is a fundamentally different operation from converting from it.
Word to PDF, Excel to PDF and PowerPoint to PDF are rendering: the source knows exactly what it means, and producing a fixed page from it is deterministic. Those conversions are dependable, and the failures are narrow and predictable — fonts you have that we do not, a spreadsheet whose print area was never set, a slide build that collapses into overlapping text because a PDF page has no sequence.
Going the other way is reconstruction. It is inference, and inference is sometimes wrong.
So the most useful habit in this whole area: keep the source file. The question “how do I convert this PDF back to Word” very often has the answer “find the document it was made from”, and that answer is always better than any converter.
How to use a converted file well
Treat it as content, not as a document. The reliable output is the words. If the destination is a template you control, paste the text into that template rather than fighting the converted formatting into shape.
Apply styles once, deliberately. Since no headings survive, selecting each heading and applying a real heading style takes a few minutes and gives you a navigable document — which is more than you started with, and more than patching bold text will ever give you.
Check pagination last. Page breaks will have moved, because the fonts moved. Fix the structure first and the breaks once, at the end.
Reconcile any numbers. If the document carries figures, check a total. Tables are the part most likely to be reconstructed imperfectly, and a column that shifted is easy to miss and expensive to publish.
The short version
A PDF records how a page looks, not what it means. Converting to Word recovers the first part almost perfectly and reconstructs the second by inference — which is why you get every word and no outline. Expect to apply styles yourself, expect line breaks to move, and keep the original source whenever one exists.
You can see the shape of it on your own file with PDF to Word: open the result, look at the navigation pane, and notice what is and is not in it.
