Fast or Complete? Comparing Firecrawl's pdf-inspector with Docling for PDF-to-Markdown

View pdf-to-md on GitHub →

Every RAG pipeline and every LLM training corpus starts with the same unglamorous step: turning documents — mostly PDFs — into clean, structured text a model can actually use. Markdown has become the de facto target format for this, because it preserves headings, tables, and reading order while staying lightweight enough to chunk, embed, or feed straight into a training run.

Firecrawl recently open-sourced pdf-inspector, the Rust engine behind their new Fire-PDF parsing stack, with a headline claim that got my attention: markdown conversion in milliseconds, with no ML models involved. Since Docling — IBM Research's document parser, now hosted by the LF AI & Data Foundation — has been my reference open-source PDF-to-markdown converter for a while, I built a small application to run the two side by side on the same documents and compare the output.

The comparison app

pdf-to-md is a Next.js application that takes one or more PDFs — individual files, a whole folder, or drag & drop — and converts each of them with both engines concurrently: Docling through its Python CLI, pdf-inspector through its Node bindings (@firecrawl/pdf-inspector). To keep the comparison fair on Docling's side, multiple PDFs are batched into a single invocation so its model-loading cost is amortized rather than paid per document.

Every run produces two markdown files per PDF plus a JSON manifest recording timings and output sizes, and the results land in a dashboard that shows the two conversions side by side along with the PDF classification and content statistics. That last part is what makes the differences discussed below immediately visible: you see what each engine kept — and what it dropped.

Two very different philosophies

The two tools could hardly be more different in how they approach the same problem.

pdf-inspector is pure Rust with a single dependency (lopdf) and deliberately no ML models at all. It works in two stages: first it classifies each PDF by sampling its internal structure — font encodings, text operators, image coverage — and labels it as text-based, scanned, image-based, or mixed, in roughly 10–50 ms. Then, for text-based pages, it extracts text with position awareness and converts it to markdown: headings, lists, code blocks, tables, multi-column reading order, even RTL support. It ships with bindings for Rust, Python, Node.js, and WebAssembly, under an MIT license.

Docling takes the opposite route: it runs a full ML pipeline — layout analysis models, TableFormer for table structure, optional OCR — and builds a rich DoclingDocument representation that captures layout, reading order, table cell boundaries, formula positions, and image placement, before exporting to markdown, HTML, or JSON. It plugs natively into LangChain, LlamaIndex, and Haystack, which is why it has become a default choice for production RAG pipelines.

Speed: pdf-inspector wins, and it's not close

This is pdf-inspector's whole reason to exist. In my tests it converts a typical text-based PDF to markdown in a fraction of a second — Firecrawl's own benchmark reports a median of 0.47 seconds for a 200-document corpus, and their hosted pipeline claims around 0.002 s per page. Because there is no model to load and no GPU involved, it runs anywhere, including in the browser via WASM.

Docling, by contrast, pays the price of its ML pipeline on every document: model loading, layout inference, table structure recognition. On a laptop without a GPU, a single scientific paper can take on the order of seconds to tens of seconds. For a one-off conversion that's fine; at corpus scale — thousands of papers for a RAG index or a training set — the difference is hours versus minutes.

Firecrawl's insight is that a large share of PDFs in the wild are text-based and simply don't need OCR or neural layout analysis. For those, a fast structural parser gets you 90% of the way at a tiny fraction of the cost.

The drawback that matters: figures

Here is where the comparison stopped being close for my use case.

The open-source pdf-inspector does not extract images. It detects that an image is there — image XObjects show up in its page classification — but the pictures themselves never make it out of the PDF. There is no way to pull the figures as files, let alone describe them.

For scientific papers, this is not a detail. A paper's figures often carry the core result: the architecture diagram, the ablation plot, the benchmark table rendered as an image. A markdown conversion that silently drops every figure produces a text that reads complete but is missing much of the substance — and a RAG system built on it will confidently answer questions while being blind to the evidence in Figure 3.

The frustrating part is that Firecrawl can do this — on firecrawl.dev, their /parse endpoint combines pdf-inspector with custom OCR and layout models that handle scanned pages, formulas (exported as LaTeX), and images. But that part of the stack lives behind their API. The open-source release is the fast structural core, not the full pipeline.

Docling handles figures end to end, fully open source. With generate_picture_images=True, it extracts every figure as an image file, keeps its position and caption in the document structure, and can go one step further: its enrichment pipeline runs a vision-language model — SmolVLM, Granite Vision, or any remote VLM endpoint — over each picture to generate a textual description (do_picture_description=True). For RAG over scientific literature, that means figures become searchable text instead of holes in the document.

One practical caveat I hit: Docling stores these VLM annotations in the document object, but doesn't automatically inline them in the markdown export — you need to serialize them yourself (this is a known open issue).

What I take away from the comparison

	pdf-inspector (open source)	Docling
Speed	Milliseconds per document, no GPU	Seconds per document, benefits from GPU
Dependencies	Pure Rust, no ML models	Full ML pipeline (layout, tables, OCR)
Tables	Heuristic + rectangle-based detection	TableFormer (learned table structure)
Scanned PDFs	Classification only — routes to external OCR	Built-in OCR
Figures	Detected but not extracted	Extracted + VLM descriptions
Best for	Fast triage and text-based PDFs at scale	Figure-rich scientific documents

The two tools are less competitors than complements, and that's how I'd actually deploy them:

Use pdf-inspector as the front door. Its classification stage is fast enough to be free — run every incoming PDF through it and let it route the document.
Let it fully convert text-only documents. Contracts, reports, documentation: milliseconds instead of seconds, at equal practical quality.
Send anything with figures or scans to Docling, with picture extraction and VLM descriptions enabled, so the visual content ends up in the corpus too.

For training data and RAG over scientific literature specifically, Docling remains my pick: completeness beats speed when the figures are the content.

The bigger picture

The PDF-to-markdown space has become one of the most active corners of open-source AI tooling, precisely because everyone building RAG or training pipelines hits this wall. Beyond these two, Marker offers a strong speed/quality balance, MinerU excels on complex and CJK layouts, and olmOCR targets scanned documents. Firecrawl open-sourcing their Rust core fits a broader pattern: the fast, deterministic parsing layer becomes a commodity, while the differentiated (and monetized) part is the neural layer on top — OCR, layout understanding, and image handling.

Which is exactly the layer scientific documents need most. Until that gap closes on the open-source side, my pipeline stays hybrid: pdf-inspector for speed, Docling for everything with a figure in it.