← Blog

PDF → Word — What no converter can do

What fundamentally cannot transfer from PDF to Word JavaScript in forms Word does not support it digital signatures incompatible mechanisms exact layout fonts, breaks will drift layers (OCG) no analogue, all merged video, 3D, audio not supported vectors → raster tools rarely emit SVG/EMF borderless tables poor detection complex forms XFA, JS do not transfer

Some failures in PDF→Word conversion are bugs that better engineering would fix. The rest are structural: the information Word needs is missing from the source, or the two formats describe incompatible models. No converter will overcome them.

1. Structure the author never expressed visually

PDF stores no logical structure. If the author drew “Chapter 14” as large bold text, the converter can guess it is a heading. If the author dropped the digits “14” on their own at the top of a page, that number is just large text — there is no link to the section that follows.

Categories that have no representation in untagged PDF:

Word treats these as named styles (Heading 1, Quote, Caption) that drive automation. After conversion you apply them by hand or live with the converter’s guesses.

The exception is tagged PDF: files carrying an explicit structure tree with <H1>, <P>, <Caption>, <Table> tags that can be extracted and used directly. PDF/UA (ISO 14289-1:2014 for PDF 1.7, ISO 14289-2:2024 for PDF 2.0) is the strict subset that guarantees complete markup. Tagged PDF appears mostly in government and corporate documents with accessibility requirements. Word’s “Save As → PDF” with the “Document structure tags for accessibility” box checked produces tagged (not PDF/UA-certified) output. A typical PDF from a browser or scanner has no tags.

2. Active forms and JavaScript

PDF supports AcroForm with text fields, checkboxes, buttons, dropdowns. Word has its own form mechanism — Content Controls. The two cross over partially:

An active PDF form converted to Word becomes static content: the visual representation of fields, with no ability to fill them in or compute anything.

3. Digital signatures

PDF supports cryptographic signatures with full PKI: certificate chains, time stamps, validation. Word’s signature mechanism (Microsoft Trust Center) is incompatible. After conversion the signature becomes a visual image or disappears entirely. Cryptographic validity, certificate chain, and time-stamping are lost. The original PDF remains signed; the converted Word file is not legally equivalent.

4. Bookmarks and navigation

PDF bookmarks form a hierarchical outline shown in the side panel. Word’s equivalent is the navigation pane built from Heading styles. The converter can transfer bookmarks as Word headings, but the back-references — the bookmark pointing to a specific page or paragraph — sometimes fail to attach. The result is a “dead” outline: entries exist, clicking them does nothing.

Hyperlinks (external URLs and internal cross-references) survive in most cases.

5. Exact layout

PDF embeds fonts to insulate itself from the recipient’s environment. Word renders against whatever fonts the recipient has installed and whatever Word version they run. Even with the same fonts, layout drifts. Conversion preserves content, not pixel-precise layout. If appearance is critical, do not convert.

6. Fonts the recipient does not have

A custom font in the original gets substituted by Word’s font fallback, the document remains readable, and the layout shifts. Embedding solves it only for license-permitted fonts and is not supported by every converter.

7. Complex tables

Categories that do not survive:

Even the best converters produce approximations.

8. Multi-column layout with wrap

Magazine layouts with sidebars, wrap, and per-page-variable column counts cannot be reconstructed cleanly by any current algorithm.

9. Layers (Optional Content Groups, OCG)

PDF supports layers — groups of graphical objects toggleable by a visible/hidden boolean. Defined in ISO 32000-2:2020, section 8.11. Used in technical drawings: utilities layer, walls layer, furniture layer.

Word has no layer model. All layers merge into one static stream. The toggle is gone.

10. Vector graphics

Vectors transfer via EMF (detail loss) or rasterization (editability loss). Technical drawings and editable graphics become static images.

11. Audio, video, 3D

PDF supports embedded multimedia — audio, video, 3D models, slideshow transitions. Word supports none of it. (Word allows embedded video objects via OLE, but the mechanism is unrelated.) All multimedia is dropped.

12. Annotations

PDF supports text comments, highlights, underline annotations, sticky notes, and stamps. Word has comments (<w:comment>) that map partially onto PDF text comments. Highlights map onto Word’s <w:highlight> text shading and most converters transfer them. Underline annotations usually disappear or get baked in as a regular underline on the underlying text. Stamps are lost.

13. Document metadata

PDF carries author, title, subject, keywords, creation date, producer. Most of it transfers to Word’s core.xml. Extended XMP metadata (Dublin Core, RDF) and custom metadata fields do not.

Practical rules

  1. Convert only when you need to edit. For reading or quoting, the PDF is more reliable than any Word derivative.
  2. Plan for cleanup. On non-trivial documents, conversion is the start of the work, not the end.
  3. Check the fragile parts first: tables, forms, footnotes, table of contents.
  4. Keep the original. Conversion is lossy and irreversible.

For documents with deep structural complexity — academic papers thick with tables, magazines with wrap, technical PDFs full of drawings — the right move is often not to convert at all: re-typeset in LaTeX, use a dedicated formula editor, or annotate the PDF in place.