Why PDF to Word Loses Formatting

The text usually survives. Almost everything about how it was arranged on the page does not. Here is the actual mechanism, not just the warning.

Last updated: August 6, 2026

PDF coordinates versus DOCX document structure

A PDF does not store "paragraphs," "headings," or "tables" as concepts at all. It stores instructions: draw this exact string of characters at this exact x/y position on the page, in this font, at this size. Every visual impression of structure - a heading looking bigger, a table looking gridded, a paragraph looking indented - is something a human reader infers from position and styling, not something the file itself labels.

A DOCX file is the opposite: it stores actual structure - a list of paragraphs, each with a style, containing runs of text - and a word processor decides where each one lands on the page at render time, which is why the same DOCX reflows differently at different window widths or font sizes. Converting from PDF to Word means inferring that second, structural representation from the first, purely positional one. NexKit PDF Tools' PDF to Word does this with a disclosed, position-based heuristic, not a layout-analysis engine - it is a genuinely different, much harder problem than converting Word to PDF, which only has to go from structure to position, never the other way.

How text order and paragraphs get reconstructed

The conversion first groups every piece of text on a page into visual lines by vertical (y-axis) position, then reflows those lines into paragraphs using a line-spacing and right-margin heuristic: if one line ends noticeably short of where the next line's text starts, or the gap before the next line is unusually large, that is treated as a paragraph break; otherwise, consecutive lines are joined into one paragraph. This is a reasonable approximation for ordinary single-column prose, and it is right most of the time - but it is an approximation, not a rule the source PDF ever actually declared.

The practical failure mode is predictable: two paragraphs that happen to be spaced close together can merge into one, and a single paragraph with unusually generous internal line spacing can split into two. Neither is random - both come directly from the same distance-based heuristic, just triggered by layout choices the heuristic cannot tell apart from an intentional break.

Why tables become flat text

There is no table-detection step in this conversion at all - not a simplified one, none. A table is, to this tool, just more text positioned in a grid. The line-grouping and paragraph-reflow heuristic described above processes it exactly like any other text: cells in the same row get read left to right (usually correctly, since they share a y-position), but the row-to-row vertical gaps that separate a table's rows are frequently similar in size to ordinary paragraph line spacing, so instead of preserving rows, the heuristic often merges an entire table into one flat paragraph - column structure gone, cell boundaries gone, only the raw text surviving in roughly left-to-right, top-to-bottom order.

Because this depends entirely on how tight a specific table's row spacing is, the outcome is not fully predictable from one PDF to the next - some simple, widely-spaced tables read out almost sensibly as flattened text; dense tables with tight rows are far more likely to blur into an unreadable run-on.

Multi-column documents and reading-order problems

Multi-column layouts expose the same y-position grouping from a different angle: the heuristic groups text into lines by height, not by which column it visually belongs to. Whether the output reads correctly depends entirely on the order the source PDF's content stream lists its text in, something invisible from just looking at the rendered page. If the PDF's internal stream lists all of the left column first and then all of the right column, extraction comes out in the correct reading order purely by coincidence of how the file happens to be structured internally. If the stream interleaves the columns line-by-line instead (left row one, right row one, left row two, right row two...), the extracted text comes out genuinely jumbled - readable words in an order no human would have written them.

There is no way to predict which case a given multi-column PDF will hit without converting it and checking, because the deciding factor is internal file structure, not anything visible on the page.

Images, headings, headers, footers, and page breaks

Images are not carried into the output at all - no photo, chart, logo, or diagram survives conversion, and no placeholder is left behind marking where one used to be. Headings are not recognized as a distinct structure either: a large bold title becomes an ordinary plain-text paragraph in the Word document, visually indistinguishable from body text once converted, because font size and boldness are visual styling this tool does not preserve, and there is no separate "this text is a heading" signal in the position data it reads.

Headers, footers, and page numbers fare the same way: they are not recognized as special regions and are not removed, deduplicated, or placed in a real Word header/footer area - they are extracted exactly like any other text on the page, typically appearing as an ordinary paragraph near the start or end of each page's content. One thing that is preserved reliably: page breaks. The output keeps one PDF page per one section of extracted text, in the original page order, even though nothing about layout, fonts, or images survives within that structure.

Realistic cleanup steps after conversion

Open the .docx and skim it against the original PDF side by side rather than assuming it converted cleanly - specifically check any page that had a table, multiple columns, or a heading you care about, since those are exactly the cases the heuristic handles least reliably. Where a table flattened into a run of text, it is almost always faster to recreate the table structure manually and paste the flattened values in than to try to coax the existing text back into a grid.

Reapply heading styles by hand wherever document structure matters for navigation (a Word "Heading 1"/"Heading 2" style, not just bold text) - the converted file has none. If images mattered, they need to be re-inserted from the original source manually; there is nothing in the .docx to recover them from. For anything converted from a multi-column PDF, read the paragraph order carefully before trusting it - a jumbled multi-column result usually needs the paragraphs manually reordered rather than lightly edited.

Frequently Asked Questions

Will my headings still look like headings after conversion?

No. Headings are not recognized as a distinct structure - a bold, large title becomes an ordinary plain-text paragraph, indistinguishable from body text. Reapply heading styles manually if document structure or navigation matters.

What happens to tables specifically?

There is no table-detection step at all. Table content is extracted as flat text using the same line-grouping heuristic as regular paragraphs, and row/column structure is frequently lost - dense, tightly-spaced tables are the most likely to merge into a single unreadable paragraph.

Why did two of my paragraphs merge into one?

Paragraph breaks are inferred from line spacing and how short a line ends compared to the next line's start position - a heuristic, not a rule the PDF declares. Two paragraphs spaced close together can fall under the same threshold and merge.

Will a two-column PDF convert in the correct reading order?

It depends entirely on how the source PDF's internal content stream orders its text, which is invisible from the rendered page - some multi-column PDFs convert correctly by coincidence of their internal structure, others come out genuinely jumbled. There is no way to predict which without converting and checking.

Are images preserved anywhere in the output?

No. Images are dropped entirely with no placeholder left behind. If images matter, they need to be re-inserted manually from the original PDF after conversion.