How to Convert PDF to Word Without Losing Formatting

Before you convert anything, check whether you can click and drag to select the text on the page. If you can, you have a native PDF and everything below applies directly. If you can't, and the whole page behaves like one flat image, you're looking at a scanned document with no text in it at all, and that changes the entire approach.

Most complaints about PDF-to-Word conversion sound the same: a table fell apart into disconnected boxes, a column merged into the wrong order, a bulleted list lost its bullets. The cause is almost always the same too. A PDF stores where things sit on a page, not what they structurally are, so the converter has to guess at structure Word actually needs to display the document properly.

TL;DR: a PDF stores positioned text and drawing instructions, not paragraphs or tables the way a Word document does, so a converter has to infer structure that was never in the file to begin with. Tables become misaligned text boxes, columns merge or reorder, and lists lose their markers because none of that structure exists to recover. A scanned PDF is a separate problem entirely: there's no text at all until OCR creates one. Checking whether your PDF is scanned, tagged, and table-heavy before you convert tells you exactly which of these to expect.

Run through three checks before you convert, because each one changes what to expect from the result. First, can you select and highlight text in the PDF, or is it a flat image you can't click into? Second, does the page use tables, multiple columns, or lists, or is it mostly plain paragraphs? Third, if you have a reader with a Tags panel, is the document actually tagged?

A flat image with no selectable text is a scanned PDF, and nothing converts until OCR creates a text layer first, covered further down. Tables, columns, and lists are the layouts most likely to come out wrong, because none of that structure exists in the PDF as an object, only as text positioned to look that way. A tagged PDF gives a converter explicit structure to work from instead of forcing it to guess from position alone, and I'll show you how to check that in a minute.

The rest of this article is the explanation behind each of these checks, and what to actually do once you know the answer.

A PDF records where every character sits on the page, not the structure that put it there. Converting to Word means the software has to infer paragraphs, columns, and tables from nothing but that positioning, which is exactly why layout drifts on anything more complex than a plain page of text. That inference works best on a PDF generated directly from text in the first place. A scanned PDF carries no character data at all, and needs optical character recognition before any conversion can start.

A Word file works the opposite way. It's a structured document: the Microsoft Open XML SDK documents a paragraph as its own distinct structural element, and covers tables as a completely separate structural element in its own right, each carrying its own formatting properties, not just characters sitting at a position on a page.

Nutrient explains the contrast plainly: a PDF's instruction to a viewer reads roughly like draw this text at this pixel position, in this font, at this size, while Word's file format reads more like this is a heading, followed by a paragraph, with a table below it. One format records where. The other records what.

This isn't a hypothetical extra step for conversion tools either. The pdf2docx documentation, for a real, currently shipping open-source PDF-to-Word converter, describes its own process as three distinct phases. First it extracts the raw data from the PDF. Then it parses that data into a layout using a set of rules, and finally generates the actual Word file. I built JoyPDF's PDF-to-Word converter around that same asymmetry. It doesn't extract a table from a PDF, because there's no table object in a PDF to extract. It detects one and reconstructs it, and that's true of every converter that's honest about how the problem actually works.

A PDF never had a table object to begin with, only text positioned in a grid pattern, so the converter has to detect that pattern and guess where the cell boundaries actually are. That guess fails more often on tables with merged cells, uneven column widths, or wrapped text inside a single cell, because the visual grid stops matching a clean row-and-column model.

Merged cells are the clearest example of why this fails. A grid-detection heuristic looks for consistent gaps between columns to infer where one column ends and the next begins. A merged cell removes that gap for exactly one row, so the same horizontal position reads as a column boundary on some rows but not others. Wrapped text creates a similar problem. A single cell holding two lines of text produces two stacked baselines. Those can look identical to two separate rows unless the converter can confirm both lines share the same left and right edge as the cell above and below them.

Recovering table structure from a PDF that carries no table tags is still an active area of computer science research, not a problem competitors have simply implemented badly. A paper on exactly this topic, on recognizing table structure in untagged PDF documents, was published at the ACM Symposium on Document Engineering in 2016. That a peer-reviewed venue is still publishing on this exact problem tells you it isn't fully solved anywhere, JoyPDF included.

In practice, that means a converter finds text laid out in rows and columns and has to decide where one cell ends and the next begins, using spacing and alignment as its only clues. A table with consistent, unmerged cells and even column widths converts far more predictably than one built for visual effect rather than actual structure.

Reading order in a PDF isn't inherent to the page. It's either explicit tagging or simply the order content happens to appear in the file's underlying content stream, and multi-column layouts are exactly where that order commonly breaks. A sidebar, a footnote, or a second column can get read as if it were a continuation of the first, because nothing in an untagged PDF marks which block actually comes first.

The W3C WCAG 2.0 Techniques, PDF3 guidance puts it plainly: pages with complex layouts, graphics, tables, footnotes, sidebars, and form fields, may not convert to tagged PDF in the correct reading order, and require manual repair even when the conversion is done deliberately for accessibility. That's a standards body describing the same failure a casual conversion produces, just in a more careful context.

If the original PDF is tagged, the tags usually preserve the intended reading order, and the conversion is more reliable. If it isn't, the converter is working from column position alone, and two columns sitting side by side on the page can come out as one merged block, read straight across the full width instead of down each column first.

A bullet or number in a PDF is just a character sitting at a coordinate, not a list property, so nothing marks it as a list item once the page's visual structure is gone. A repeating header or footer has no distinct tag either unless the PDF is tagged, so the converter can place it back into the body text in reading order instead of recognizing it as a running header.

The same mismatch affects images and text boxes. Content anchored to an absolute coordinate on a PDF page doesn't map cleanly onto Word's relative anchoring model, where objects are usually tied to a paragraph or a margin rather than a fixed position. That's why an image sometimes lands in a different spot, or a text box detaches from the paragraph it was meant to sit next to, once the file opens in Word.

One thing worth separating out here: if text near a list or header comes out in an entirely different typeface, or shows blank boxes instead of letters, that's a related but different cause. I've covered why fonts substitute or garble during conversion in its own article, and it's worth checking if the layout looks right but the actual characters don't.

A scanned PDF has no text inside it at all, only a photograph of a page, so nothing can convert to Word until optical character recognition creates a text layer first. Everything explained above about tables, columns, and lists assumes there's actual text to reason about. A scanned page has none of that until OCR runs.

You can tell a scanned PDF from a native one with a few practical checks, all drawn from the GROBID project guide. Check whether you can select and highlight any text at all, and whether the file size looks unusually large for its page count. Two more signals help too: whether text visibly pixelates when you zoom in, and whether the file's Producer metadata field names a scanner driver or an OCR engine instead of a word processor or design tool.

OCR's job is character recognition and nothing more. It turns a scanned PDF into something with real text in it, but recognizing characters isn't the same as recovering structure. GROBID's own project guide, built around extracting structure from scholarly PDFs, states plainly that OCR alone doesn't hand back a document's structure either. Recovering layout, which block was a heading, which one was a table, is a separate and harder problem than recognizing which pixels form which letter. LlamaIndex describes multi-column layouts and tables specifically as where that structural recovery breaks down, producing the right characters read back in scrambled order. That's why OCR output typically has weaker structural fidelity than text pulled straight from a native PDF: OCR has only pixel positions to work from, with nothing else to check against.

I've covered how to tell whether a scanned PDF has a text layer and how to fix it in more depth elsewhere, including the specific detection steps. If that's genuinely your starting point, it's worth reading first. Once you know OCR is needed, run OCR on a scanned PDF before converting it, then treat the result the same way you'd treat any native PDF from there.

A tagged PDF gives a converter explicit structure, paragraph roles, table roles, reading order, to work from instead of forcing it to guess from position alone. That's why the same converter can handle one PDF cleanly and mangle another that looks nearly identical. Tagging is the difference between structure being stated and structure being inferred.

PDF/UA, the ISO standard for accessible PDF, requires explicit table, row, header, and data-cell role tags for a document's structure to be machine-readable. Without those tags, Nutrient explains the problem directly. A reader can try to guess what's a heading, what's a paragraph, and what order to read things in. At the end of the day, it's still guesswork.

You can check whether a PDF is tagged yourself in under a minute. In Acrobat, open the View menu, then Show/Hide, then Navigation Panes, then show the Accessibility tags panel. In some Acrobat versions that means right-clicking an empty area of the navigation pane and choosing Accessibility tags rather than finding Tags listed as a direct submenu item. The built-in Accessibility Check flags a Tagged PDF pass or fail result specifically, and like the panel, it can only detect whether tags exist, not whether they're structured correctly.

Match what you're actually seeing against the table below to find the likely cause and the fastest fix, rather than working back through every mechanism above one at a time. Find your symptom in the left column, what actually happened during conversion in the middle, and what to do about it on the same row.

Check whether the PDF is native or scanned before anything else, since that decides your whole approach. Run OCR first if it's scanned, keep tables and columns as simple as the content allows if you have any control over the source document, and check the tags panel if the result comes out structurally wrong, so you know whether the converter had real structure to work from or only position.

Once you know what you're dealing with, you can convert your PDF to an editable Word file in your browser without uploading it anywhere first. That's worth knowing if the document is a contract, a resume, or anything else you'd rather not hand to a third-party server just to change its file format. The file is processed on your device, and it's never sent anywhere to make the conversion happen.

If you've hit the mirror-image version of this problem, a Word document that changed formatting on its way to becoming a PDF, that's the reverse problem, converting Word to PDF, and the causes there are different enough that I've written about it on its own.

None of this guarantees a flawless result on a genuinely complex document. What it does is tell you in advance which parts are likely to need a manual pass afterward, a merged-cell table, a multi-column page, anything that started out scanned, so the result doesn't surprise you.

A PDF has no document structure to preserve, only positioned content, so nothing about a table, column, or list survives conversion as an object, only as an educated guess. Tables and columns are inferred, not extracted, which is why complex ones need more cleanup than simple ones.

A scanned PDF needs OCR before anything else, since there's no text to convert until then. A tagged PDF converts more reliably, because it hands the converter real structure instead of forcing it to guess from position alone.

Check what you're actually dealing with before you convert, not just after you're disappointed by the result. Once you know whether the PDF is native or scanned, simple or table-heavy, tagged or not, you know exactly which of the problems above to expect, and which of them you can head off before they happen.