PDFtoMD
AI WorkflowsOllamaLM StudioLlama

Optimize PDFs for Local LLMs: Ollama, LM Studio, and Open-Source Models

Local models like Llama 3 and Mistral have strict context windows. Converting PDFs to Markdown before feeding them to Ollama or LM Studio can double the usable content per prompt.

7 min readBy Rafael Abellan

You have decided to run LLMs locally. Maybe you are protecting proprietary data that cannot leave your network. Maybe you are optimizing for latency and cost — running Llama 3 on your own GPU is infinitely cheaper than paying per-token to OpenAI or Anthropic. Maybe you love the control and the freedom that open-source models give you.

But you have just hit a hard problem: context window limits. Your Llama 3 model has a 8K context window. Your Mistral 7B has 32K. Your local setup maxes out at 64K if you are running a beefy setup. And suddenly, you realize that feeding PDFs directly into these models is wasteful — the raw PDF contains layout instructions, page headers, footers, and formatting junk that crushes your token budget before you even get to the actual content.

Converting PDFs to clean Markdown before feeding them to Ollama, LM Studio, or your local inference engine can double or triple the usable content per prompt. Here is how to do it, and why it matters more for local LLMs than for expensive cloud APIs.

Why Local LLMs Hate PDFs (More Than Cloud Models)

Cloud LLMs like Claude or GPT-4 give you massive context windows — 200K tokens, 128K tokens — so a poorly formatted PDF is annoying but not catastrophic. You can afford the waste.

Local models are the opposite. Every token costs you:

  • Inference time. More tokens = longer generation. On a consumer GPU, this is noticeable.
  • VRAM overhead. A 7B model + a 16K context window fits on an RTX 4090. Add 50K tokens of noisy PDF garbage, and suddenly you are swapping to RAM (10x slower).
  • Quality degradation. Large models trained on diverse data still struggle with PDFs. They see formatting as noise, not signal. Markdown clarifies intent.

This is why Markdown is not optional for local LLMs — it is architecturally necessary.

How PDFs Waste Your Token Budget

Let us use a concrete example. You have a 20-page technical whitepaper (PDF, 50MB with embedded images). You want to feed it to your local Claude-running setup (16K context Mistral) along with a question.

The PDF, when converted to raw text, is 25,000 tokens. But that number is misleading:

  • Layout instructions: "Line at pixel 100, 243 with width 500" — repeated 500 times for formatting. 2,000 tokens wasted.
  • Embedded metadata: PDF object IDs, font definitions, color spaces. 1,500 tokens wasted.
  • Repeated headers/footers: Page number "15" on every page. 200 tokens wasted.
  • Image descriptions: Raw image binary converted to text. 3,000 tokens wasted (or error if images are skipped).
  • Inconsistent spacing: The OCR engine misread columns as separate lines. Semantic structure is lost. The model wastes inference budget trying to infer structure. 5,000 tokens of low-confidence reasoning.
  • Actual useful content: 12,000 tokens.

You have just burned 11,700 tokens to get 12,000 tokens of real content. That is a 49% token efficiency loss.

Now convert the same PDF to clean Markdown. No layout instructions. No embedded metadata. Proper heading hierarchy. Lists formatted clearly. The same 20-page whitepaper is now 10,000 tokens of pure content.

With your 16K context Mistral, you now have room for:

  • 10K tokens of document
  • 3K tokens of conversation history
  • 2.5K tokens of reasoning space
  • 0.5K tokens of output buffer

With the PDF version (25K tokens), you would exceed the context window entirely. You cannot even fit the document.

When to Convert PDFs for Local LLMs

You do not need to convert every PDF. Here are decision rules:

Convert if:

  • Your context window is < 32K tokens (Llama 2, Mistral 7B base, local Phi)
  • Your document is > 5 pages (will likely exceed 30% of your context window)
  • You are running on consumer hardware (RTX 3080 or less) where VRAM is precious
  • You are asking complex multi-document questions (need context for multiple files)
  • You need reliable citations or fact-checking (PDFs confuse LLMs; Markdown is clearer)

Skip if:

  • Your local model is 70B+, running on enterprise GPU (VRAM is abundant)
  • You have a 128K context window (like Mistral Large or Llama 3 70B)
  • The PDF is a short form (1-2 pages) and you have ample context room
  • The PDF is purely visual (blueprint, diagram, infographic) — Markdown would lose information

How to Convert PDFs for Ollama / LM Studio

Option 1: Use PDFtoMD (Recommended)

Upload your PDF to PDFtoMD, get clean Markdown in seconds. Then copy-paste directly into your Ollama prompt or save to a local file for your RAG pipeline.

Advantages:

  • Zero code. Works in your browser.
  • Handles images gracefully (preserves alt-text descriptions).
  • Tables are converted to readable Markdown tables (not garbled text).
  • Maintains heading hierarchy automatically.

Option 2: Command-Line Tools (for Batch Processing)

If you are processing many PDFs, use command-line tools that integrate with your Ollama workflow:

  • pdftotext + post-processing: pdftotext is fast and built into most Linux systems. Output is rough but useful if you clean it with regex.
  • PyPDF / pypdf: Python library. Use it to extract text, then clean with Markdown formatting rules.
  • Claude API in batch mode: Expensive but highly accurate — send 100 PDFs to Claude with "convert this PDF to clean Markdown", get perfect output, feed to local Ollama. Works if cost is not a blocker.

Option 3: Build a Local RAG Pipeline

The ultimate solution: convert PDFs to Markdown once, chunk by semantic sections (not by token count), embed with a local embedding model (sentence-transformers), store in a vector DB (Chroma, Milvus, Pinecone), and then at query time, retrieve only the relevant chunks.

This solves the context window problem permanently. You never feed the whole document — you feed only the relevant 2-3 chunks.

We wrote a full guide on RAG pipelines with Markdown.

Practical Example: Ollama + Markdown

Here is a real workflow:

Step 1: Convert PDF

# Upload my-whitepaper.pdf to PDFtoMD
# Download markdown-output.md
# Save locally: ~/documents/my-whitepaper.md

Step 2: Prepare the prompt in a shell script

#!/bin/bash

DOCUMENT=$(cat ~/documents/my-whitepaper.md)
QUESTION="What are the key architectural decisions in this system?"

curl http://localhost:11434/api/generate -d '{
  "model": "mistral",
  "prompt": "Document:\n\n'"${DOCUMENT}"'\n\nQuestion: '"${QUESTION}"'\n\nAnswer:",
  "stream": false
}'

Step 3: Get response

The Mistral 7B model now sees clean, structured content. It can cite sections accurately and reason clearly about the document.

Pro Tips for Local LLM + Markdown Workflows

1. Chunk by Section, Not by Token Count

When building RAG for local LLMs, split your Markdown by semantic sections (h2 headers), not by token count. This preserves context and improves retrieval quality.

# Good (semantic chunking)
chunks = split_by_heading(markdown_text, level=2)

# Bad (naive token chunking)
chunks = split_every_500_tokens(markdown_text)

2. Use Markdown Metadata

Add YAML front-matter to your converted Markdown files:

---
title: "System Architecture Whitepaper"
date: 2026-01-15
source: "acme-corp-systems.pdf"
section: "Technical"
---

# Introduction
...

Your RAG system can use this metadata to filter documents by date, source, or category before chunking.

3. Compress Long Lists

If your Markdown has long itemized lists, compress them for local LLMs:

# Before (wastes tokens)
- Feature 1: description
- Feature 2: description
- ... 50 more items

# After (more efficient)
Features: 1) name, 2) name, 3) name, ... 52) name

4. Remove Boilerplate and Appendices

Local LLMs have small context. Remove sections that are unlikely to be relevant:

  • Copyright notices (keep the essential one)
  • Full appendices (link or summarize instead)
  • Detailed references (cite, do not quote)
  • Duplicate content across chapters (merge or cross-reference)

5. Test Your Token Budget

Before you deploy a Markdown document to your local LLM pipeline, count tokens:

import tiktoken

with open("document.md") as f:
    tokens = len(tiktoken.encoding_for_model("gpt2").encode(f.read()))
print(f"Document: {tokens} tokens")
print(f"Available context: 16000 - 2000 (buffer) = 14000")
print(f"Fit: {tokens <= 14000}")

The Bigger Picture: Why This Matters

Running LLMs locally is becoming standard for companies handling sensitive data, optimizing costs, or building AI-first products. But local means constraints — no unlimited context, no 10x safety margin.

Converting PDFs to Markdown is not just a nice-to-have optimization. It is the difference between a workflow that barely fits in your context window and one that leaves room for multi-document reasoning, conversation history, and thought.

Plus, Markdown is version-controllable. You can track when you updated a document, why, and what changed. PDFs are black boxes; Markdown is a Git-friendly artifact.

Getting Started

Start small:

  1. Pick one PDF you are regularly feeding to your local model.
  2. Convert it to Markdown (PDFtoMD takes 30 seconds).
  3. Copy-paste into your next Ollama prompt.
  4. Notice the difference in response quality and generation speed.

Once you see the benefit, move to batch conversion + RAG. Your local LLM setup will thank you.

Convert your PDFs to clean Markdown and fit more usable content into every local LLM prompt.

Rafael Abellan

About the author

Rafael Abellan

Founder, PDFtoMD

Rafael Abellan is the founder of Agência Triva and ships independent side projects in parallel. PDFtoMD came out of a personal frustration: he kept burning through Claude AI's token limit by uploading long PDFs, then losing hours waiting for the cap to reset. He built the tool to fix his own workflow, and now uses it every day.

Ready to convert your PDFs to Markdown?

Free account · 3 conversions/month · No credit card required