What a PDF-to-Word conversion actually does, seen through its step log

Converting a PDF to an editable document is usually described as one action. It is not. A real run from this site contains eight recorded steps, two of which are failures that the pipeline recovers from. The log is worth reading because it explains both the price and the failure behaviour.

The step log of one successful job

inspect_document              pypdf-docx-editable     884 ms
  extract_document_content     pypdf-docx-editable     644 ms
  render_document_page         pypdf-docx-editable     482 ms  error: unsupported_renderer
  convert_to_editable_document compact_spacing         424 ms  error: strategy_requires_optimization
  convert_to_editable_document (retry)                1357 ms
  validate_editable_document                           4289 ms
  optimize_document_candidate  compact_spacing        1040 ms
  validate_editable_document (after optimise)          3875 ms

Two of those lines are errors, and the job still succeeded. That is the design: an error in a step is information the loop uses, not a verdict on the document.

Why it renders its own output

The step that matters most is validate_editable_document, and it takes the longest — 4.3 seconds in this run. What it does is render the DOCX it just produced back into an image and compare that against the source page. Text coverage, missing numbers, table structure, merged cells, borders, text outside page bounds.

This is the difference between "the conversion ran" and "the conversion produced something usable". A pipeline that stops after writing the file has no idea whether the file is right; a checker that only reads the DOCX XML can confirm the paragraphs exist while the rendered page has lost half the text. Rendering it back is how you find out.

The unsupported_renderer error at step three is the honest version of the same idea: the renderer that was tried could not do the job, so the pipeline says so rather than skipping verification and pretending the output was checked.

The repair loop

When validation finds a problem, the pipeline does not immediately fail. It optimises the candidate — in this run, a compact-spacing strategy to fit content that had overflowed — and validates again. The two conversions in the log are the same document converted twice with different strategies, and the first attempt was explicitly rejected by the optimisation gate before the second was tried.

This is why a successful job takes 35 to 70 seconds on this site while a failed one takes 12 to 32. The failure aborts the loop; success runs it to the end, including at least one full re-render and comparison. Paying for the slow path is the point: the fast path is what produces documents that look fine and are missing a column.

What failure means here

Of the conversions recorded on this site, seven failed and nine succeeded. All seven failures carry the same error code, agent_execution_failed, meaning the loop exhausted its repair attempts rather than hitting a billing or network problem. In every case no file was published and the reserved credits were released.

That distinction matters when you are deciding whether to retry. A failure here is a statement about the document — this scan did not survive conversion within the attempts available — not about the service being down. Uploading the same file again will usually fail the same way. Uploading a better scan, or a digital PDF instead of a photograph of one, changes the outcome.

What the successful ones still warn about

Every successful conversion on this site carries the layout_approximate warning, and that is not a defect being excused. Converting a fixed-layout page into a flowable document means fonts and spacing cannot match the original — the original had no reflowable structure to preserve. A page image could match exactly, but then nothing would be editable, which defeats the purpose.

Knowing which of the two you need is most of the decision. If the document must look identical, you want a PDF, not a Word file. If it must be editable, approximate layout is the price, and the useful question becomes whether the text, numbers and tables survived — which is exactly what the validation step measures.