PDF to Markdown for AI: RAG, Claude, ChatGPT (2026)

Why PDF to Markdown matters for AI

If you have ever pasted a PDF into Claude or ChatGPT and watched the response stumble — repeated headers, broken paragraphs, table cells in the wrong order — the format is the problem. PDFs were designed for print. They encode visual layout, not document structure. Tokenizers see every page header, footer, and column break as content, which fattens the context window and drowns out the actual signal.

Markdown solves this by stripping the layout and preserving the structure. Headings stay headings. Lists stay lists. Tables stay tables. Headers, footers, and page numbers — the noise — get filtered out. The result is text that reads cleanly to a human and parses cleanly to an LLM.

The numbers back it up. On a 50-page government circular, the raw text extraction from PDF.js produced about 38,000 tokens (Claude tokenizer). The Markdown conversion, with headers and footers removed, came to 24,000 tokens — a 37% reduction with the same information density. On a per-million-token basis at Claude Sonnet 4.6 input pricing ($3/M), that is the difference between $0.114 and $0.072 per query. Across a thousand queries a day, that is $1,500 a year, on one document.

For retrieval-augmented generation (RAG), the case is even stronger. RAG quality depends on chunk boundaries that respect semantic structure. Markdown headings give you those boundaries for free — LangChain's MarkdownHeaderTextSplitter and LlamaIndex's MarkdownNodeParser both split on heading levels by default. Raw extracted PDF text gives you nothing structural; you end up chunking on character count, which slices through paragraphs and tanks retrieval precision.

4 methods compared

There are four serious options for PDF-to-Markdown in 2026. Each has a different tradeoff profile.

1. Marker (datalab.to)

Marker is the highest-fidelity option. It uses a stack of vision-language models to recognize equations, complex tables, multi-column flow, and figures with captions. On academic papers, the output is nearly print-quality. The catch: it needs Python, PyTorch, and a GPU for the deep model — practical for batch ingest on a server, not for ad-hoc conversion. The hosted API at datalab.to is paid and uploads your PDF.

2. MarkItDown (Microsoft)

Open-sourced by Microsoft in late 2024 and stable through 2026. CPU-only, fast, handles office documents (PDF, DOCX, PPTX, XLSX) with a single CLI. Output quality is solid for business PDFs but weaker on equations and complex tables compared to Marker. Pure-Python install, no GPU required.

3. pymupdf4llm

The lightest pure-Python option. Built on PyMuPDF, optimized for RAG ingest, no model dependencies. Sub-second conversion on a typical business PDF. Output is opinionated for LLM consumption — strips visuals, preserves logical flow. Default choice if you are running a Python ingest pipeline and do not need vision-model fidelity.

4. PDF Mavericks (browser-local)

The only browser-local option in this set. Drop the PDF, get Markdown, no server upload, no install, no API key. The tradeoff: text-layer-only conversion, so scanned PDFs need OCR first (run our browser-local OCR tool first if your PDF is image-based). For text-based PDFs — the majority of contracts, reports, articles, and manuals — the output is interchangeable with pymupdf4llm. The privacy story is the differentiator: when the PDF is a salary slip, a bank statement, or an Aadhaar copy, server-upload tools are non-starters.

Quick decision rule. Academic papers with equations and figures, server-side batch: Marker. Office documents, server-side: MarkItDown. RAG ingest pipeline in Python: pymupdf4llm. One-off conversion in your browser, sensitive document: PDF Mavericks.

How to convert in PDF Mavericks

The flow is three steps:

1. Open the PDF to Markdown tool. The page loads in under a second; nothing downloads beyond standard JavaScript.
2. Drop your PDF on the drop zone, or click "Choose PDF" and pick a file. The tool reads the PDF directly from your local file system using the browser File API.
3. Click "Convert". The conversion runs in WebAssembly. A 50-page PDF takes 6 to 12 seconds on a modern laptop. The output appears in a copy-able text area; click "Download .md" to save it.

That is it. No upload, no signup, no quota. The Markdown is yours; do whatever you want with it.

Plugging the output into a RAG pipeline

The Markdown output is structured for chunking by heading. Two minimal-effort splits work well in practice:

LangChain. Use MarkdownHeaderTextSplitter with H2 and H3 as split levels. Each chunk gets the heading path as metadata, which improves retrieval precision because the embedder sees the section context. For a 60-page report, this typically produces 80 to 140 chunks — a workable number for a vector store.

LlamaIndex. Use MarkdownNodeParser with default settings. It produces hierarchical nodes that mirror the heading tree, which lets you do parent-child retrieval — fetch the small chunk for embedding match, return the parent section for context.

For embeddings, a 768- or 1024-dim model is fine. Mistral Embed and Voyage 3 both index Markdown well; OpenAI's text-embedding-3-small is the cheap default. Skip embedding the headings themselves as separate chunks — they bias retrieval toward generic matches.

3 pitfalls to avoid

1. Do not skip the OCR step on scanned PDFs. A "PDF" that is really a stack of images has no text layer. Conversion will produce empty Markdown. Run OCR first; we have a browser-local OCR tool that adds the text layer in-place. The whole chain stays local.

2. Do not include encrypted PDFs without unlocking. Bank statements and tax documents in India often arrive password-protected. Browser PDF readers cannot extract text from encrypted PDFs. Unlock first using our unlock-pdf tool (also browser-local), then convert. The unlock tool needs the password — it does not crack anything; it just removes the encryption layer once the password is supplied.

3. Do not feed the Markdown raw into a 200K context model expecting magic. Even with clean Markdown, a 200K-token context window has retrieval challenges — the "lost in the middle" problem is real, even on Claude. For documents above ~80K tokens, RAG outperforms long-context insertion in most benchmarks. Convert, chunk, embed, retrieve. The Markdown conversion is step one of a four-step pipeline, not the whole answer.

When to convert and when to skip

Not every PDF needs to become Markdown. If you only need a one-shot summary and the PDF is under 30 pages, pasting the raw text into Claude or ChatGPT works fine — the model handles light noise. The conversion pays off when one of three things is true: the PDF is part of a recurring pipeline (RAG, Notion ingest, weekly report), the PDF is sensitive enough that server-upload tools are off the table, or the document is large enough that token cost per query starts mattering. For everything else, raw paste is the cheaper path.

For India-specific workflows — bank statements, tax documents, government circulars, salary slips — the privacy story drives the choice more than token economics. Even a small PDF gets converted in-browser when uploading it to a third party would be a compliance headache. The 6-second conversion is cheap insurance against a data exposure that does not need to happen.