Decide what the research agent must preserve

A PDF converter can return readable text while losing the relationship between a number, its table header, and the reference supporting the surrounding claim. For a research agent, the useful question is not simply whether a document can become Markdown. It is which evidence must survive that conversion.

Start with the next operation. A rough reading aid needs a different output contract from a table extraction workflow or a citation-aware literature map. This guide compares MarkItDown, Docling, and GROBID against those contracts. They are document-processing tools, not three interchangeable SKILL.md packages; a skill may orchestrate them, but packaging does not remove their operational differences.

Methodology and selection criteria

We reviewed the three projects' primary documentation on September 9, 2026. Selection was based on the output representations and document-processing capabilities they describe, not GitHub popularity. We did not run conversions, compare accuracy, or measure latency.

Our recommendations below are editorial inferences from those documented capabilities. The acceptance exercise is a proposed evaluation you can perform on documents you are authorized to process. It is deliberately small: the purpose is to expose a mismatch before scaling, not to establish a universal benchmark.

MarkItDown: start with a text handoff

Microsoft's MarkItDown repository documents conversion of PDFs and other file formats into Markdown, with optional dependencies and integrations. It also distinguishes local built-in conversion from cloud-backed options and optional model-assisted features.

We would evaluate this approach first when the immediate requirement is readable material for an agent, especially across mixed office-document formats. Keep the original file beside the converted output. Do not assume that a plain-text handoff preserves every relationship needed for later quantitative analysis.

Make the configuration part of the review. A package name alone does not tell you whether a particular conversion uses an external service. Record the enabled converters and plugins rather than describing every installation as offline or free.

Docling: evaluate document structure explicitly

Docling's repository describes PDF layout and reading-order processing, table structure, OCR, a unified document representation, and exports including Markdown and JSON. It documents local execution capabilities and notes that model licenses need separate consideration from the code license.

We would put Docling on the shortlist when your downstream workflow needs more than a sequence of paragraphs. Preserve the structured output during the pilot rather than discarding it immediately after generating Markdown.

That recommendation is not a claim that Docling will correctly interpret every table. Your acceptance test should inspect the specific structures your agent relies on. A successful conversion and a correct relationship between a cell and its header are different checks.

GROBID: evaluate bibliographic relationships

GROBID's introduction describes extraction into structured XML/TEI with an emphasis on scientific and technical publications. Documented functions include publication metadata, references, citation contexts, full-text structure, and coordinates for extracted information.

We would consider it when bibliography and citation relationships are central outputs rather than incidental text. Plan for a consumer of the structured result; flattening it at the first step can discard the relationships you chose the parser to obtain.

A parsed reference is not proof that the cited work supports a claim. Matching a citation marker to a bibliography entry and assessing scientific support are separate tasks. Preserve that distinction in the agent's instructions and final report.

Build a three-document acceptance set

Choose three representative files from your own workload: a text-based paper with multiple columns, a report containing a table important to your question, and a scanned document. If you never process scans, substitute another known difficult format rather than testing a capability you do not need.

For each file, manually identify a small set of facts before conversion. The following record is our proposed evidence contract:

Original identity: file name, content hash, and a source URL where available.
Location: page and a human-readable description of the relevant section or table.
Target: the exact field, passage, or citation relationship to recover.
Expected interpretation: units, row and column labels, or the bibliography entry.
Review status: confirmed, ambiguous, missing, or not applicable.

Run only configurations you have reviewed and authorized. Keep converter versions and options with each result. For a table, check one ordinary row and one edge case such as a missing cell or footnote. For citations, check whether a marker points to the intended entry, not merely whether both appear somewhere in the output.

Do not let the downstream agent fill missing values from plausibility. An explicit missing result is easier to investigate than a polished but unsupported answer.

Route failures before scaling the workflow

Use separate outcomes for conversion failure, unreadable structure, and uncertain interpretation. These failures require different responses: retrying an infrastructure error, choosing another parser, or asking a human to inspect the original.

Our suggested routing rule is to accept an output only for the contract it passed. A file may be suitable for a rough summary while remaining unsuitable for table-based evidence. Record that narrower status rather than assigning the document one blanket success label.

When comparing configurations, include review time and the cost of ambiguous results. A local pipeline still consumes compute and maintenance; an optional remote feature may introduce billing and data-transfer considerations. This article supplies no price or performance estimate.

Limitations and choosing the next step

Three documents cannot establish production accuracy. Languages, publisher layouts, scans, and unusual equations can change the result. Expand the evaluation with observed failures, and repeat relevant checks when the parser or configuration changes.

For discovery, inspect the MarkItDown registry entry and Docling registry entry, then verify the actual upstream package you plan to use. A listing is not evidence that your PDFs were tested.

Choose the smallest pipeline that preserves your required evidence. The milestone is not producing a large folder of Markdown files; it is being able to trace a research claim back to the correct source without silently inventing what the parser missed.