How to convert a PDF to Word

A PDF does not store paragraphs. It stores glyphs — individual characters, each with a font reference and a position on the page. There is no sentence, no heading, no list; those are things a human eye assembles from spacing. Every PDF-to-Word converter in existence, ours included, is therefore doing reconstruction rather than translation: it reads thousands of positioned glyphs and guesses which of them belong to the same line, which lines belong to the same paragraph, and which paragraph was meant to be a heading. Understanding that one fact explains almost everything about the results you get — why a clean report converts beautifully, why a two-column academic paper comes out interleaved, and why a scanned contract produces an empty document no matter which tool you use.

What the converter actually reads

The text layer of a PDF is a list of drawing operations. Each one says, in effect, place this string of glyphs from this font at this x and y coordinate, at this size. A converter walks that list and starts grouping. Glyphs that share a baseline within a small tolerance become a line. Lines whose vertical gap matches the surrounding leading become a paragraph; a gap noticeably larger than the leading ends it. Font size and weight relative to the page's most common body size decide what becomes a heading — a line set 40 per cent larger than the body text and followed by a normal-sized paragraph is almost certainly a heading, and gets written into the .docx as one rather than as bold text. Bullet and number markers at the start of a line, followed by a consistent indent on the lines beneath, become list items. None of this is stored in the file; all of it is inferred, and the inference is what separates a usable output from a wall of loose lines.

Where reconstruction goes wrong

Three layouts break the assumptions. Multi-column pages are the classic case: two columns sitting side by side share baselines, so a naive reader stitches the left column's line to the right column's line and produces nonsense. A converter has to detect the column gutter and read each column to the bottom before moving across. Tables are the second: a table is drawn as text at coordinates plus, sometimes, lines — but often with no lines at all, so a table and a neatly spaced list of figures are visually identical to the parser. The third is a document whose headings are numbered. A line beginning "1. Scope of Services" looks exactly like the first item of a numbered list, and the ordering of the two tests inside the converter decides which one you get. We hit this ourselves and had to move the heading test in front of the list test, because a numbered heading is far more common in the documents people actually convert than a one-item list.

Scanned PDFs produce nothing, honestly

If a page was produced by a scanner or a phone camera, it contains one large image and no text layer at all. There are no glyphs to group, so there is nothing to reconstruct. A tool has two options: return an empty document, or run optical character recognition to invent a text layer from the pixels. We do not do OCR, so we refuse the file and say why instead of handing you a .docx with three blank pages in it. This matters more than it sounds — in a small sample of real-world documents we tested with, three of five readable PDFs turned out to be scans. If your file falls into that group, the honest next step is an OCR tool, and you should treat its output as a draft to proofread rather than as recovered text: OCR guesses characters from shapes, and confident wrong guesses are its normal failure mode.

Fonts, encoding and the mojibake problem

A second, quieter failure mode is character mapping. A PDF can embed a font subset with its own internal glyph numbering and supply a table that maps those numbers back to real characters. When that table is missing or wrong — common in files produced by older typesetting software, and in documents whose Turkish, Greek or Cyrillic characters were substituted at print time — the extracted text comes out as plausible-looking garbage: correct word shapes, wrong letters. There is no way for a converter to repair this from the file alone, because the information simply is not there. The tell is that the same document also fails to search correctly in a PDF reader: try Ctrl+F for a word you can plainly see on screen, and if the reader cannot find it either, the mapping is broken and every extraction tool will produce the same mess. In that situation the original source document, not the PDF, is what you want.

Judging the output before you trust it

Open the .docx and check four things in order. First, does the text run in the right order — read the first page end to end, because column stitching errors are obvious there and invisible in a spot check. Second, are the headings real headings? Click one and look at the style box; if it says Heading 1 you can rebuild a table of contents, if it says Normal you have bold text and nothing more. Third, look at any table: check that a value has not slipped a column. Fourth, search for a number you know is in the middle of the document — a total, a date, an invoice line — and confirm it survived, because dropped content is the failure that costs you most and shows up least. Our own verification suite runs exactly this last check on every build, precisely because it is the one a human reviewer skips.