Mistral OCR for PDF-to-Markdown Conversion (2026 Review)

Direct answer: Mistral OCR is a hosted API (model id mistral-ocr-latest, first shipped as mistral-ocr-2503 in March 2025) that turns a PDF or image into structured Markdown, page by page, with tables, math, and embedded images preserved. It is a good fit when you want a single API call, do not want to run models yourself, and are comfortable sending documents to a third-party endpoint. It is a poor fit when documents cannot leave your environment, when you need per-page routing logic, or when you want Markdown assembled locally with no per-page bill. Priced at roughly $1 per 1,000 pages, it is cheap to try and easy to reason about.

This is a practical review for developers building extraction into an LLM or RAG pipeline: what Mistral OCR returns, how you call it, where it does well, where it does not, and how to decide between a hosted OCR API and a local tool. If you are still comparing the broad field first, start with which PDF extractor should you use.

What Mistral OCR actually returns

Mistral OCR is not a plain text-dump OCR. It reconstructs document structure and serializes it to Markdown, which is what makes it interesting for LLM pipelines rather than for scanning receipts into a search box.

For each page you send, the API returns:

• Markdown for that page, with headings, lists, and tables kept as Markdown syntax rather than flattened into a run of text.
• Extracted images, returned inline as base64 (or by reference), with placeholders in the Markdown so you can re-insert figures where they belong.
• Page dimensions and index, so you can map output back to the source page.

The important design choice is that output is page-scoped. A 40-page report comes back as 40 Markdown blocks plus an image list, not one merged document. You concatenate them yourself. That is more work than a tool that hands you one Markdown file, but it gives you clean page boundaries — useful when you chunk for retrieval and want to keep page numbers as metadata. For the chunking side of that, see PDF chunking strategies for RAG.

Mistral positions two layers on top of the raw OCR:

1. OCR — the document-to-Markdown conversion described above.
2. Document understanding / Document AI — pairing OCR output with a chat model so you can ask questions against a document in one flow, or pull structured fields with a schema.

For a pure extraction pipeline you usually want layer 1 and your own downstream logic. Layer 2 is convenient for quick document Q&A but couples you to Mistral’s chat models as well as its OCR.

Calling it from Python

The call itself is short. You upload or point to a document and name the OCR model.

import os
from mistralai import Mistral

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

# Point at a hosted URL, or upload a file first and pass a signed URL.
resp = client.ocr.process(
    model="mistral-ocr-latest",
    document={
        "type": "document_url",
        "document_url": "https://example.com/report.pdf",
    },
    include_image_base64=True,
)

# One entry per page.
for page in resp.pages:
    print(f"--- page {page.index} ---")
    print(page.markdown)

To send a local file, upload it to Mistral’s files endpoint first, get a signed URL, then pass that URL to ocr.process. The Python and TypeScript SDKs, plus request samples, are in the Mistral cookbook on GitHub. Rebuilding a single Markdown document is a concatenation step:

full_markdown = "\n\n".join(page.markdown for page in resp.pages)

That is the whole integration. There is no model download, no GPU, no local dependency beyond the SDK — which is precisely the trade you are making.

Where it does well

Structure-heavy documents. Financial statements, research papers, and forms come back with tables as Markdown tables and equations as LaTeX rather than as scrambled text. If your downstream step is an LLM, structured Markdown reads far better than raw OCR text.

Multilingual and mixed-script pages. Mistral advertises support across thousands of scripts and languages, and in practice it handles mixed Latin/Arabic/CJK pages without a separate language flag. If Arabic or right-to-left content is your main concern, compare notes with Arabic PDF OCR.

Scanned and photographed pages. Because it is an OCR-first model, it does not care whether text is a real text layer or a photograph of a page. Born-digital and scanned inputs go through the same call.

Cost predictability. At about $1 per 1,000 pages, a 50,000-page backfill is on the order of $50. There is no GPU to rent and no per-hour compute to reason about — you pay per page, full stop.

Where it does not

Data leaves your environment. Every page is uploaded to Mistral’s API. For contracts, medical records, or anything under a data-residency rule, that is often a hard stop regardless of how good the output is. Mistral offers enterprise and self-managed options, but the default cloud API is not local.

No routing. Every page costs the same and takes the same path, whether it is a clean born-digital page that a fast parser could read for free or a noisy scan that genuinely needs OCR. In a mixed corpus that is money spent on pages that never needed a vision model. Routing born-digital pages away from OCR is exactly the optimization described in PDF extraction routing in Python.

Per-page output assembly. You get pages, not a document. Re-inserting extracted images and stitching pages into one file is on you. It is not hard, but it is code you own.

Vendor coupling for accuracy claims. Mistral publishes its own accuracy benchmarks, and they are strong on its chosen test sets — but they are the vendor’s numbers on the vendor’s data. Treat them as a starting point and run your own sample of 20 to 50 representative pages before committing a pipeline. That advice is not specific to Mistral; it applies to every extractor, which is why we keep pushing real-world benchmarking over published scores.

Mistral OCR vs a local tool: the honest comparison

The useful comparison is not “which model is smarter.” Both produce Markdown that an LLM can read. The comparison is about deployment, control, and cost shape. Here is how Mistral OCR lines up against a local, self-hosted tool such as pdfmux.

Read that table as a decision, not a scoreboard. If you are prototyping, handling a few thousand pages, and your documents are not sensitive, the hosted API is the shortest path — one key, one call, predictable bill. If your documents cannot leave your environment, or you are processing millions of pages where a fast path for born-digital pages saves real money, a local tool wins on the axes that matter. For the hosted-vs-hosted alternative, pdfmux vs LlamaParse covers the other popular API.

A decision checklist

Answer these before you pick:

1. Can documents leave your environment? If no, stop here and go local.
2. What is your monthly page volume? Under ~100,000 pages and not sensitive, a hosted API is simplest. Above that, model the per-page bill against self-hosted compute.
3. Is your corpus mixed born-digital and scanned? If mostly born-digital, routing saves you from paying OCR prices for pages that never needed OCR.
4. Do you need one Markdown file or page-scoped chunks? Mistral gives you pages; decide who assembles them.
5. Have you tested your own 20–50 pages? Never ship on a vendor benchmark alone.

Mistral OCR is a clean, well-built API and a reasonable default for hosted extraction in 2026, especially on multilingual and structure-heavy documents. The reasons to reach for a local tool instead are almost never “the output is worse” — they are data residency, cost at volume, and the ability to route pages so you only pay for the OCR you actually need. Decide on those axes and the choice makes itself.

If you want the Markdown-for-LLM output shape without sending documents anywhere, see PDF to Markdown for RAG.