Converting PDF to an editable document

Where PDF came from, and why it is like this

PDF and word processor formats are opposites, and every difficulty in this conversion comes from that.

A word processor document is a sequence of content: these paragraphs, in this order, with these styles, and the software decides where the page breaks fall. A PDF is the opposite — it is the finished output, a record of where every glyph was placed on a fixed page. It does not know it has paragraphs. It knows that a character appeared at a particular coordinate, and then another one nearby.

Converting back means reconstructing intent from position: guessing that these glyphs form a word, these words a line, these lines a paragraph, and that this block on the left is a column rather than the start of a sentence continued on the right. Reasonable-looking output on a simple document, and unreliable on anything with columns, tables or sidebars.

Is this conversion lossy?

Heavily, and the losses are structural rather than visual.

What comes across is the text. What generally does not is the layout: multi-column pages tend to interleave, tables lose their cell structure and arrive as runs of text, headers and footers land in the body, and images and vector art are not reconstructed at all. Fonts are replaced with whatever the destination has.

The reliability depends almost entirely on how the PDF was made. One exported directly from a word processor converts well, because the text is present as text and laid out simply. One produced by a design tool, or by scanning, converts badly or not at all.

What happens to metadata, transparency and colour

A scanned PDF produces nothing. This is the single most important thing to know. If the pages are photographs of paper, there is no text in the file to extract — only pixels — and the conversion will return an empty or nearly empty document. It has not failed; there was nothing there. OCR is the tool for that file, and it is a different operation entirely.

Document metadata is not carried. Title, author and creation date do not move to the output.

Formatting is approximate. Bold and italic often survive because they are properties of the font in use; paragraph styles, numbering, indentation and spacing generally do not.

Anything interactive is dropped — form fields, links, annotations, comments and bookmarks have no equivalent in the extracted text.

Why people actually need this

Needing to change something in a document you no longer have the source for. A contract that needs a clause amended, a CV in PDF that needs updating, a report someone sent as a PDF and cannot find the original of. The text exists and is uneditable, and retyping it is the alternative being avoided.

The second situation is reuse: pulling a few paragraphs out of a long PDF into something else, where the layout does not matter because the text is going somewhere with its own layout.

What we measured

This conversion was run end to end before this page was written. Not "should work" — run, with the output checked:

And the ceilings measured for PDF to Word, the tool that performs it, on the hardware described on the limits page:

Not tested

The page also refuses files above 50 MB before it starts, which is a guard written into the tool rather than something the browser imposes. Why those are different.

When something else is the better answer

If the PDF is scanned, use OCR. Nothing else will work, and this conversion will look broken when it is in fact correct.

If you only need the words and not a document, extracting the text is faster and produces cleaner output — no attempt at layout reconstruction means nothing to go wrong.

If the document is mostly a table, expect this to go badly. The cell structure is not in the PDF in a recoverable form, and reading the table as a table is more likely to give you something usable.

If the original file exists anywhere, use it. Every conversion here is a reconstruction, and the source is not.