PDF to Markdown Converters in 2026: Choose by Document Type
The best PDF-to-Markdown converter for your workflow is the one that preserves the information your documents contain and produces output your downstream tools can use. Start with document type, then test reading order, table relationships, missing pages, and mathematical notation.
For selectable, single-column text, a local extractor is a sensible baseline. For scans, you need an OCR-enabled path. For complex tables or layouts, compare reconstruction options rather than assuming that either a text extractor or a vision model will always win.
We build Markovo. This guide includes it as a hosted option, not as an independent winner. Official capability descriptions were reviewed for this revision on October 19, 2026. The measured examples below come from an archived October 6 synthetic-PDF experiment, not new tests of the latest versions of every tool.
Start with the document you actually have
| Document type | A useful starting point | What decides whether it works |
|---|---|---|
| Selectable, single-column prose | Local text extraction or a lightweight Markdown converter | Complete sentences, paragraph order, headings required by the destination |
| Digital PDFs with simple tables | A Markdown converter or configurable table extractor | Headers, units, row-to-column assignments, output table format |
| Multi-column reports and papers | Layout-aware extraction, with or without model assistance | Order across columns, captions, sidebars, and page boundaries |
| Scans or mixed digital/scanned documents | Explicitly configured OCR plus layout processing where needed | Visible text recovered on every required page, including embedded images |
| Formula-heavy material | A path with mathematical recognition or reliable native-text extraction | Source symbols, subscripts, superscripts, and rendered expressions |
| Sensitive or restricted documents | An approved local or private deployment | Data handling, dependencies, model downloads, and any remote calls |
A single file can belong to several rows. A readable first page does not prove that the appendix scan was processed. A table that renders attractively does not prove that a total belongs to the correct item.
Compare technical routes, not generations
Several techniques can coexist in one converter:
- Text and geometry extraction uses existing PDF text and positioning information. It can avoid recognition errors on reliable text, but still needs rules for reading order and structure. pdfminer.six documents layout analysis, so describing every text extractor as a simple file-order dump is inaccurate.
- OCR recognizes words from pixels. It is essential when required words are absent from a usable text layer. OCRmyPDF adds a searchable text layer to scanned PDFs; that output is not, by itself, a finished Markdown document.
- Layout and table reconstruction determines block order and relationships between cells, headings, figures, and captions. It may use geometry, learned models, or both.
- Vision-language document processing can generate structured text from rendered pages. Its output still needs checks for omission, altered numbers, and incorrect mathematical notation.
These are workflow choices, not a maturity ranking. Hybrid processing is not inherently inferior to an end-to-end vision path. Choose based on the resulting document and the cost of correcting it.
The tools, with configuration boundaries
The table describes documented capabilities and evaluation questions. Unless a tool appears in the historical results section below, we are not claiming to have measured its PDF output for this guide.
| Tool or family | Documented role | What to verify for your deployment |
|---|---|---|
| pdfminer.six / pypdf | Local extraction from PDF text; layout-related controls vary | Markdown structure must be created or checked separately. pypdf is not an OCR engine. |
| pdfplumber | Character/geometry inspection, text extraction, configurable table extraction, and visual debugging | Table strategies and regions need to match the document. A raw extract_text baseline does not test its tuned table capabilities. |
| PyMuPDF4LLM | Markdown-oriented extraction with table, image, page-chunk, layout, and OCR controls | The project repository now directs users to PyMuPDF 2.x. Distinguish the legacy 1.28.2 test from current installation and OCR setup. |
| MarkItDown | A common conversion interface for multiple formats | Built-in PDF extraction, an optional OCR plugin, and Azure backends are distinct paths. |
| OCRmyPDF | OCR preprocessing that adds searchable text to PDFs | Plan the subsequent Markdown and layout conversion; OCR text alone does not establish table structure. |
| Docling | Structured document conversion with layout, tables, OCR, and multiple export formats | Select pipeline and export options. Formula and picture enrichments are configurable features, not a blanket promise about every default run. |
| Marker | Document conversion with layout/OCR processing and Markdown/JSON output | Check the selected mode, inference backend, model requirements, and licenses. Current documentation includes CPU/Apple Silicon paths as well as GPU configurations. |
| MinerU | Model-based parsing with several local processing configurations | Hardware and dependencies depend on the selected tier and backend; do not assume every configuration requires an NVIDIA GPU. |
| olmOCR | A document-processing toolkit using a vision-language model | Review model-serving requirements, input coverage, output format, and deployment cost. |
| Mathpix | OCR for text, math, tables, and STEM content, with Mathpix Markdown output | Check output-dialect compatibility, pricing, retention, and deployment. Documentation also describes Private Cloud OCR, so “hosted only” is too broad. |
| Markovo | Hosted conversion through web and authenticated developer workflows | Inspect actual Markdown and bundle contents, account requirements, Credit estimates, and source fidelity. A quality field is not an independent correctness score. |
Before adopting any tool, review the terms for the exact code, models, and services you use. “Open source” does not mean zero compute cost, identical model licenses, or no deployment obligations. This guide does not provide legal conclusions about your application.
What our historical PDF test does and does not show
The archived test used eight synthetic PDFs with paired expected content. It ran MarkItDown 0.1.8 with plugins disabled, PyMuPDF4LLM 1.28.2 with the recorded default call, and pdfplumber 0.11.10 using raw text extraction, under Python 3.11.14. Markovo outputs came from the recorded October 6 service batch and were cached for scoring.
The full scores, local run log, and cached Markovo batch record are available. No Marker, MinerU, Docling PDF, olmOCR, Mathpix, MarkItDown OCR-plugin, or Azure result is established by this particular experiment.
| Check on one specified fixture | MarkItDown | PyMuPDF4LLM | pdfplumber text baseline | Markovo cached output |
|---|---|---|---|---|
| Single-column prose recall / order | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 |
| Simple-table row / leaf-header score | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 | 1.0 / 1.0 |
| Two-column prose recall / order | 0.1111 / 0.8 | 1.0 / 1.0 | 0.1111 / 0.8 | 1.0 / 1.0 |
| Scan-only sentence recall | 0.0 | 0.0 | 0.0 | 1.0 |
| Mixed-document page-anchor coverage | 0.6667 | 0.6667 | 0.6667 | 1.0 |
| Linear-expression normalized string recall | 1.0 | 0.75 | 1.0 | 0.5 |
These scores are narrow checks, not percentages of general document accuracy. Row and header metrics look for expected strings on the same output line, not correct merged-cell semantics. The equation metric measures normalized expression strings, not mathematical equivalence.
All Markovo batch entries have from_cache=true and elapsed_s=0.0. Those values cannot support a speed comparison. The rate-card identifier is a billing version, not a converter version. The current capabilities in the tool table should not be confused with configurations tested on October 6.
Reading order: preserve complete passages
On the two-column fixture, MarkItDown and the raw pdfplumber baseline interleaved sentences. PyMuPDF4LLM and Markovo preserved the tested sentence sequences. That directly contradicts a blanket claim that a text-based Markdown tool necessarily fails on columns.
In your own sample, compare a paragraph crossing a column boundary, a figure caption, and a sidebar. Keyword presence is not enough if a reader encounters fragments in the wrong order. A successful result on one clean two-column page is also not evidence for every journal layout.
Tables: check relationships and representation
All four recorded paths retained the expected row strings and leaf labels in the simple invoice fixture. MarkItDown and PyMuPDF4LLM emitted pipe tables; raw pdfplumber did not; Markovo emitted HTML tables.
On the merged-header and rotated-header fixtures, MarkItDown and PyMuPDF4LLM passed the row check but failed the leaf-header check. Markovo passed both string checks, but those checks still do not certify correct parent-header spans or value-to-column assignments. Review the table against the PDF.
A more useful acceptance question than “does it contain a table?” is: can the downstream reader identify the correct item, quantity, unit price, and total without guessing?
Scans and formulas: evaluate them separately
The recorded local configurations omitted scan sentences; the cached Markovo results recovered them. That does not mean the local projects lack every possible OCR route. In particular, MarkItDown has an optional OCR plugin and Azure integrations, and PyMuPDF4LLM documents OCR configuration.
The linear-expression fixture favored the local text paths over Markovo under the saved matcher. It contained textual expressions, not spatial fractions or matrices. Do not use scan recognition results to infer equation fidelity, and do not treat plausible LaTeX as proof that a minus sign or subscript is correct.
Actual output from a synthetic PDF
This is the complete archived Markovo output for table-simple.pdf, linked from the PowerPoint guide's independent PDF probes. It is PDF evidence, not an XLSX dashboard conversion:
## Quarterly invoice summary
<table><tr><td>Item</td><td>Qty</td><td>Unit Price</td><td>Total</td></tr><tr><td>Consulting hours</td><td>12</td><td>85.00</td><td>1020.00</td></tr><tr><td>Data export fee</td><td>3</td><td>40.00</td><td>120.00</td></tr><tr><td>Template license</td><td>1</td><td>190.00</td><td>190.00</td></tr><tr><td>Support retainer</td><td>6</td><td>55.00</td><td>330.00</td></tr><tr></tr></table>
The result preserves useful table content, but includes HTML and a trailing empty row. Test it in your renderer and parser. A destination that accepts pipe tables but removes raw HTML needs a different representation or a validated transformation.
The service documentation lists deliverables such as Markdown, assets, source maps, and quality reports. Check the files actually returned for your job. Their presence supports inspection; it does not prove every figure, formula, or page is correct.
How to compare candidates on your own documents
- Choose a small representative set. Include ordinary pages and the hardest examples: columns, merged headers, rotated labels, scans, low-resolution images, and equations relevant to your work.
- Write explicit acceptance checks. Require complete paragraphs, correct header-to-value relationships, required pages, and intact equations. Add links and assets if your destination needs them.
- Record the configuration. Save tool and model versions, enabled OCR/enrichments, hardware, page ranges, and output format.
- Keep unedited outputs. Evaluate conversion separately from cleanup so manual repair does not become an unreported advantage.
- Test the destination. Render Markdown and run the real parser or retrieval workflow. A table can survive conversion but be lost during HTML sanitization or chunking.
- Measure total cost. Include runtime, model setup, hosted charges, manual review, failed jobs, and retry behavior. Separate cold starts from steady-state processing and cached outputs from fresh runs.
Public datasets can supplement your own samples. OpenDataLoader-Bench evaluates reading order, tables, and headings; DP-Bench provides another document-parsing evaluation resource. Inspect dataset versions, engine settings, and individual outputs before transferring a score to your workload. A self-run result should not be described as an official leaderboard position unless the official board actually lists it.
Where Markovo is worth trying
Markovo is an option when you prefer a hosted workflow over maintaining local extraction and model dependencies. Start with the PDF to Markdown converter, review the estimate and account requirements, and compare the downloaded output with the source. For developer integration, use the current API and CLI documentation.
If the source is an image rather than a PDF, use the image-to-Markdown workflow. If you still have the native Word file, spreadsheet, or presentation, evaluate native conversion separately. A good XLSX table result does not establish PDF table quality, and a slide-face PDF cannot supply speaker notes it never contained.
Frequently asked questions
Is there one best converter in 2026?
Not from the evidence here. Shortlist by document type, deployment constraints, and output requirements. The archived experiment shows different strengths even within eight small PDFs, and it does not compare all tools or current versions.
Do I need a vision model for RAG?
Not simply because the destination is RAG. Reliable native text may already contain what retrieval needs. Use OCR or layout processing when the source requires it, and test whether chunks preserve headings, table context, units, and provenance. Retrieval cannot restore a page omitted during extraction.
Does Markdown conversion preserve the PDF's design?
Treat it as content and structure extraction, not a replacement for the original layout. Keep source images or page references when visual relationships matter, and check whether your destination supports the table and math syntax produced.
Is “OCR supported” enough to choose a tool?
No. Check the installed version, engine, language data, model or service configuration, and whether OCR actually ran on the required content. Then compare the output with the source.
For hands-on local troubleshooting, continue with MarkItDown for PDFs or PDF to Markdown in Python. Choose the simplest path that passes your checks, and keep difficult pages reviewable.
