I converted a two page report to Word to check something, and the second paragraph came back as this:
Revenue rose in the third Headcount grew by four, quarter on the back of two all in support. The hiring large renewals signed in plan for the fourth quarter August. Margin held flat. is unchanged at six roles.
Two columns of perfectly ordinary prose, read across the gutter line by line, so every sentence is spliced into the one beside it. Nothing was broken. The converter did exactly what a converter can do, and the gap between that and what the phrase "PDF to Word" promises is the entire subject of this guide. Every output quoted below came from running the conversion, not from describing it.
TL;DR: A PDF stores glyphs at coordinates. It does not store paragraphs, columns, tables or headings, so a converter has to infer them from positions, and some of those inferences are wrong in ways you can predict. Measured on a test report: two columns interleaved line by line, a four row table flattened to one line reading "Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166", a heading merged into the paragraph below it, and a page with no text layer produced nothing at all. What you reliably get back is editable prose in page order, which for most jobs is what you wanted. The PDF to Word converter does it in the browser, so the document is not uploaded.
What is stored inside a PDF?
Instructions for painting a page, not a document.
A PDF's content stream says things like "set this font at this size, move to x 60, y 720, show these glyphs". The specification itself is a description of a painting model, and the text operators sit alongside the ones for drawing lines and filling shapes. There is no object in the file that means "paragraph", no object that means "this is a table", and nothing that records that two blocks of text are columns rather than one wide one. The format was designed so a page prints identically everywhere, and it achieves that by describing the page as marks rather than as content.
So a converter receives a list of positioned runs. pdf.js, the parser this runs on, hands them back exactly as the page draws them. In the test file, page one produced 34 of them and page two produced 4. Each run is a string with an x, a y, a width and a font height, and the order they arrive in is the order the page was drawn, which is not necessarily the order you would read them.
Everything a Word document needs that a PDF does not have, the converter has to reconstruct from those four numbers. That reconstruction is the whole of what follows, including everywhere it goes wrong.
How does a converter rebuild paragraphs from coordinates?
In two passes, with a threshold on each.
The first pass groups runs into lines by baseline: runs whose y values sit within half a font height of each other are one line. The second groups lines into paragraphs by the vertical gap between them. A gap larger than about 1.45 times the usual line spacing starts a new paragraph, where "usual" is the median gap on that page rather than a fixed number, so the rule adapts to a document set in 9 point or 14 point.
There is a third threshold inside a line. pdf.js often splits a single word across several runs with no gap between them, so joining runs on a space turns "filename" into "f i l e n a m e". The fix is to insert a space only when the horizontal gap exceeds a quarter of the font height, which is about the width of a real word space.
These three numbers decide almost everything about the output. When the result is good, they were right. When a heading sticks to the paragraph below it, the gap was under 1.45 times the median and the rule said one paragraph.
Why do two columns come out interleaved?
Because the only evidence for a column is a horizontal gap, and the line grouping looks at vertical position first.
The two blocks in my test page sat at x 60 and x 320, with their lines on shared baselines. The grouping saw six baselines, each carrying text from both sides, and read each one across. The result is the paragraph at the top of this guide: every line of the left column followed immediately by the line beside it.
This is the same failure as scrambled columns in OCR, and it has the same root: reading order is a judgement about a layout, made from geometry, by something that cannot read.
Converters that handle columns well do a page segmentation step first, looking for a consistent vertical band of whitespace running the height of the page and splitting the page there before any line grouping. That works on a newspaper or a journal paper, where the gutter is wide and regular. It is less reliable on the common cases, where a sidebar, a pull quote or a two column table breaks the band.
If your document has columns, the practical answer is to check the output and fix the first paragraph of each page, or to convert a column at a time if the document is long enough to be worth it.
What happens to a table?
It becomes a sentence.
My test file had a four row table with three columns. Here is the whole of it after conversion:
Region Q2 Q3 EMEA 412 455 AMER 388 401 APAC 120 166
Every value survived. The structure did not. You cannot tell from that line that 412 is EMEA's Q2 figure without counting positions and knowing the shape of the original.
The reason is that most PDFs do not contain tables either. A table in a PDF is usually text drawn at coordinates with some lines drawn around it, and the lines are graphics operations that have nothing in the file connecting them to the text they enclose. A converter would have to detect the alignment of the numbers, infer a grid, and decide which runs belong to which cell, which is a research problem rather than a parsing one.
Some PDFs do carry real structure, through tags added for accessibility, and those convert far better. They are a minority: tagged PDFs come from a careful export out of Word or InDesign, not from a print driver.
If the table is the thing you want, copy it into a spreadsheet by hand, or convert the PDF to text and reshape it there. A converted Word file will not give you cells.
Why did my heading merge into the paragraph?
Because the space under it was not big enough to trip the paragraph rule.
On page two of the test file, the heading "Notes" sat 40 points above the body text while the body lines were 18 points apart. That gap is 2.2 times the line spacing, which should have split them, and it did not, because the median gap on a page with only four runs is not a reliable estimate of anything. The output was:
Notes Note 14 covers intercompany revenue and the treatment of
deferred items carried over from the prior year.
This is the honest shape of the whole problem. Threshold rules work well on a page with enough text to establish a baseline rhythm and poorly on a sparse one. A title page, a short note, a cover sheet or a form will often come back as one run-on paragraph.
It is also the easiest thing to fix after the fact. Headings are obvious to a human reader, and pressing return in the right place takes a second, which is less time than any tool would take to get it right.
What happens to a scanned page?
Nothing comes out, and that is the correct behaviour.
The third page of my test file had no text layer at all, only a grey rectangle standing in for a scan. pdf.js returned zero runs and the converter produced zero paragraphs for it.
The page is still counted. It appears in the Word file as an empty page, so the page breaks after it stay aligned with the original, which matters when someone is working from page numbers. A converter that silently dropped it would shift every later page by one.
A PDF whose pages are all images is a scan, and no converter can extract text from it because there is no text to extract. What that needs is OCR, which reads the picture of the letters and guesses at the characters, and which brings its own error rate. The measured version of that trade is in the guide on what breaks OCR: tilt past three degrees is what ruins a scan, not resolution.
A useful rule of thumb: open the PDF and try to select a sentence with your cursor. If the text highlights, a converter can read it. If you get a selection rectangle over an image, you need OCR first.
What is inside the .docx that comes out?
Three files in a zip, and that is genuinely all it takes.
A .docx is an Open Packaging Convention archive, standardised as ECMA-376: a zip containing XML parts plus a manifest saying what each part is. Microsoft's own overview of the format walks the same three parts. The minimum that opens as a Word document is three entries:
| Part | Purpose |
|---|---|
[Content_Types].xml |
Declares the media type of every part in the package |
_rels/.rels |
Points at the main document part |
word/document.xml |
The content itself |
Everything else a Word file usually carries, styles, fonts, themes, settings, numbering definitions, is optional. Leave them out and the reader applies its defaults.
The test document, 83 words over three pages, came to a 1,305 byte .docx whose word/document.xml is 1,169 bytes. I opened it with Apple's own document reader, which is what TextEdit and Pages use, and it rendered every paragraph in order with the page break intact. A minimal package is not a degraded one.
One detail in that XML matters more than it looks. Every run is written with xml:space="preserve". Without it, a run beginning or ending with a space loses it, and every line that was wrapped in the original comes back with its last word joined to the next one.
What happens to the images?
They are dropped, and the Word file does not mention it.
The package written here has three parts and none of them is a media part. A logo, a chart, a scanned signature, a screenshot embedded in the report: all gone, with no placeholder where they were. The text that surrounded them closes up as though they had never been there.
This is a consequence of the same design that makes the output small and reliable. Carrying an image across means extracting it from the PDF, deciding its format, writing it into word/media/, adding a content type for it, adding a relationship part, and placing a drawing element at the right point in the flow. Each of those is a place for a reader to reject the file, and a .docx a word processor refuses to open is worse than one missing a logo.
It matters most for the documents where an image is the content rather than decoration. A chart in a report converts to nothing, and a reader of the Word file has no way to know a chart was ever there. Check the original alongside the conversion when a figure is being referred to in the prose.
Why does the file sometimes refuse to open at all?
Control characters, which XML forbids and PDFs contain.
A PDF's text layer picks up characters from whatever produced it: form feeds from a print pipeline, null bytes from a broken encoding, other C0 control codes that mean nothing in a document. XML 1.0 does not allow most of them, even escaped: the character range the specification permits begins at tab, newline and carriage return and skips the rest of the C0 block.
The failure is not graceful. Word does not warn or drop the character; it refuses to open the file and says the content is unreadable. So the converter strips those characters before writing, rather than trying to escape them. They carried no meaning in the source and they would cost you the whole document.
If you ever receive a .docx that a word processor rejects as unreadable, this is the first thing to suspect, and it is why a converter writing XML by hand has to think about it at all.
Should you convert to Word or to plain text?
Word if you are going to edit it, text if you are going to process it.
They share the same extraction. The difference is only what gets written at the end: one writes paragraphs into a zip of XML, the other writes them into a .txt file.
| You want to | Use | Because |
|---|---|---|
| Edit the prose and send it on | PDF to Word | Paragraph structure, page breaks, something a colleague can open |
| Search, grep, or feed it to a script | PDF to text | No markup in the way |
| Keep the layout exactly | Neither | Edit the PDF, or get the original file |
| Read a scan | OCR first | There is no text layer to extract |
The third row is the one worth sitting with. If the layout is what matters, converting to Word is the wrong direction, because the conversion is where the layout is lost. Ask whoever sent the PDF for the file it was exported from. It takes one message and it is the only approach that keeps the formatting.
How long does the conversion take?
Long enough to read the file, and no longer.
There is no encoding step and no image processing. The work is parsing the PDF structure, pulling the text content of each page, grouping runs, and serialising XML into a zip. The test file took a few milliseconds, which is not a useful number because it was three pages. A two hundred page report is bounded by pdf.js parsing it, which is roughly linear in the number of pages and fast.
What you do notice on a large document is memory, because the whole file is held in the browser tab along with the parsed structure. That is the real ceiling here rather than speed.
What should you check in the output?
Four things, in the order they are likely to be wrong.
- The first paragraph of every page. This is where column interleaving and heading merges show up.
- Any table. Confirm the numbers are present, then accept that the grid is gone and rebuild it if you need it.
- Hyphenated words at line ends. A word broken across a line in the PDF comes back with the hyphen in the middle of it.
- Page count. It should match the original, including any blank or scanned pages.
That list takes a minute on a ten page document and is the difference between a file you can send on and one that quietly contains a spliced sentence.
Why does this run in the browser?
Because the documents people convert are contracts, statements, letters, medical results and things under embargo.
The conversion is a parse and a zip, both of which a browser does perfectly well. The file is read from your disk into the page, parsed there with pdf.js compiled for the web, assembled into a .docx in memory, and handed back as a download. No request carries the document, nothing is stored on a server, and nothing exists for anyone to delete later.
The usual alternative is a site that takes your PDF, converts it on a machine you know nothing about, and emails you a link. For a public leaflet that is fine. For an employment contract it is a decision you were not asked to make consciously.
The cost is the tab's memory on very large files, and no server-side OCR for scanned pages. Both are visible limits rather than quiet ones, which is the trade worth having.
