PDF-to-Markdown tools differ because the documents and workflows differ. A browser converter, a Python library, an OCR service, and a GPU-backed layout model can all be the right answer. Ranking them with one accuracy score hides the factors that determine real effort: text layer, layout, privacy, scale, installation, and review.
Use this guide to narrow the choice before running a representative test.
Start with the document layer
Try to select and copy a sentence from an ordinary body page. If it pastes correctly, the PDF has a usable text layer and a lightweight parser may work. If the page is an image or copied text is empty, OCR is required. If the text is garbled, a broken font mapping may justify OCR even though glyphs are present.
Check more than one page. Reports can mix digital chapters and scanned exhibits. Note languages, rotations, and handwriting. A page-level decision is sometimes more accurate than a file-level decision.
For classification details, use the text versus scanned PDF guide.
Score layout complexity
Simple documents have one column, ordinary paragraphs, clear headings, short lists, and few tables. Coordinate-based extraction can often reconstruct them well.
Moderate documents add headers, footers, occasional two-column pages, simple tables, and images. They need more cleanup and representative testing. Complex documents include scientific formulas, dense columns, floating figures, forms, merged table headers, handwriting, or unusual scripts.
Do not infer complexity from page count. A 300-page single-column manual may be easier than a four-page brochure. Choose the hardest required page as part of the test set.
Decide where data may go
For public PDFs, convenience may dominate. For internal or personal data, determine whether processing may occur in a third-party cloud. Browser-side and local tools can keep source files on the device, but device security and downstream services still matter.
Cloud services may offer strong OCR without local setup. Review their retention, region, subprocessors, account controls, and contract. Do not equate TLS with a no-access policy.
If extracted Markdown will later enter a model or vector database, include that transfer in the decision. The private conversion threat model maps these layers.
Match the tool class
A browser text-layer converter is best for clean PDFs, quick individual or small batch work, no installation, and local processing. It is not the right choice for image-only scans or math-heavy layouts.
A command-line library such as MarkItDown fits automated pipelines and multiple input formats. It offers reproducibility and scripting but requires an environment, dependency maintenance, and engineering around failures.
Layout-aware projects such as Marker and MinerU target complex papers, tables, formulas, and reading order. They can run locally but require models, memory, and more compute. Their output still needs review.
OCR tools are necessary for scans. Tesseract can run locally and is useful for controlled cases; commercial or cloud models may perform better on difficult layouts and languages. Data handling and cost become part of the design.
Define the output requirement
“Markdown” can mean readable prose, publication-ready pages, RAG input, or a faithful archival derivative. These are different acceptance criteria.
For reading notes, coherent sections may be enough. For documentation, links, code, headings, assets, and stable slugs matter. For RAG, provenance and chunk structure matter. For tables, CSV may be better than Markdown. For legal or scientific evidence, page traceability and critical-value review are essential.
List required structures and allowed omissions before testing. A tool should not be penalized for omitting images if images are out of scope, nor accepted for fluent prose if formulas are required.
Measure total workflow cost
Zero purchase price does not mean zero cost. Include installation, model downloads, compute, page charges, review, repair, upgrades, and operational monitoring. A lightweight converter followed by ten minutes of cleanup may beat a complex pipeline for one report. A calibrated local model may save weeks across an archive.
Consider failure isolation. Can the tool report which file and page failed? Can it resume a batch? Does it overwrite output? Can you record version and configuration? Operational behavior matters at scale.
Avoid benchmarking only speed. A fast wrong table is not useful, while a slow high-fidelity parser may be unnecessary for plain prose.
Run a representative comparison
Choose pages containing ordinary text, the hardest layout, a table, links or lists, and any critical values. Run each candidate with documented settings. Compare reading order, character accuracy, headings, lists, tables, equations, links, and omitted content.
Record repair time as well as raw output. A tool that produces a slightly less polished first draft may still win if its errors are predictable and easy to automate. Conversely, fluent but inconsistent errors are expensive to detect.
Use the same source and evaluation criteria. Do not compare marketing examples from different documents.
Plan review and provenance
No extraction method removes the need for proportionate review. Sample ordinary documents and fully review high-risk structures. Preserve source checksum, tool version, conversion date, warnings, and output checksum. Failed files should remain visible failures.
For batches, use deterministic checks for empty or unusually short output, invalid encoding, missing headings, and duplicate results. The batch QA guide provides a complete workflow.
A concise decision tree
If the page is a scan, choose OCR. If text copies correctly and the layout is simple, start with a browser or command-line text parser. If columns, formulas, or tables are central, test a layout-aware model. If privacy prohibits cloud transfer, keep every processing and downstream step local. If the output must feed a maintained site or knowledge system, prioritize provenance and automation over one-off appearance.
The right tool is the least complex workflow that meets the document's acceptance criteria. Test the boundary honestly, keep source evidence, and switch tools when the document—not the product category—demands it.
