Quick answer

The safest PDF-for-RAG workflow is: classify the file first, run OCR before Markdown on scanned pages, clean the structure before chunking, and only then ingest it into your knowledge workflow.

The order matters because a messy source will usually create retrieval problems long before you should blame the retriever or the model.

Start with file type, not with chunk size

Before you talk about chunking, decide which of these three source types you have:

• Born-digital PDF : text is already selectable and the file comes from a normal authoring workflow
• Scanned PDF : text is still an image and cannot be selected or copied reliably
• Hybrid PDF : some sections are digital, while other sections are scans, screenshots, or photographed pages

This classification matters more than people expect. It tells you whether the next step should be direct Markdown conversion, selective OCR, or a smaller page-scope workflow before anything enters the AI ingestion stack.

When OCR should happen first

If the pages that matter are still image-based, OCR should usually happen before Markdown. Otherwise the system is trying to recover structure from visual guesses instead of usable text.

That is especially true when:

• the file is a scanned manual or photographed report
• only some appendices or tables are scanned inside a larger digital packet
• the downstream goal is reliable section chunking
• the team will later quote or retrieve exact wording

In pdfClaw, that means starting with PDF OCR . If only one section is image-based, isolate it first with Split PDF rather than OCRing an entire packet by habit.

Why Markdown is useful for RAG

Markdown is useful because it turns implicit page structure into explicit text structure.

That usually improves:

• heading-aware chunking
• section-level retrieval
• paragraph and list integrity
• table readability when structure survives
• source reuse in docs, Git, or AI workflows

A PDF may look consistent to humans, but it often hides ambiguity about where a heading begins, where a list ends, or whether a line belongs to body text, a footer, or a caption. Markdown does not solve every layout problem, but it makes structure easier to preserve and inspect.

The four cleanup steps that matter most

People often treat conversion and cleanup as separate concerns. In practice, cleanup is what makes conversion useful.

1. Fix heading hierarchy

If headings collapse into plain paragraphs, chunking becomes much weaker. Check whether section titles still behave like section titles.

2. Remove repetitive noise

Headers, footers, page numbers, and duplicated page furniture often pollute retrieval more than users expect. Remove them before indexing.

3. Validate tables deliberately

For RAG, a table does not have to look beautiful. It does have to keep the right values under the right headers. If table meaning breaks, retrieval quality breaks with it.

4. Keep images traceable

Not every image has to remain embedded. But a chart, architecture screenshot, or figure should remain discoverable and attributable if the downstream workflow needs it.

Choose an image strategy on purpose

For AI workflows, the useful question is not “did the image survive?” It is “can the system still understand that there was an image here, and can the team get back to it later?”

Three common strategies are practical:

• external image references for Git-style or docs workflows
• embedded assets when single-file handoff matters more than size
• placeholder-only output when the image is secondary but the surrounding structure still matters

What matters is consistency. A RAG pipeline is much easier to debug when image handling follows one predictable rule instead of changing document by document.

Chunk after the structure is stable

Chunking too early creates the illusion of progress. In reality, it just locks unstable structure into the retrieval layer.

Chunk after you have checked:

• the heading map
• repeated page furniture
• critical table meaning
• image representation
• source metadata that must stay with the document

The goal is not just smaller pieces of text. The goal is smaller pieces of reliable text.

A practical preparation workflow

Use this sequence when you want a repeatable PDF-to-RAG pipeline:

1. identify whether the document is born-digital, scanned, or hybrid
2. if relevant pages are scanned, run PDF OCR first
3. if only part of the file matters, isolate it with Split PDF
4. convert to PDF to Markdown
5. clean headings, repeated page furniture, and critical tables
6. choose an image strategy
7. attach source metadata if trust or freshness matters
8. chunk only after the content is structurally stable

This workflow is boring in the best possible way: it prevents many downstream “AI quality” problems that are really source-quality problems.

What to validate before you index anything

If you want a fast acceptance pass instead of a long abstract checklist, validate these five things on one representative document before you batch-ingest a whole set:

1. can you search for a heading and get the right section?
2. when you copy one table-adjacent paragraph, does the reading order still make sense?
3. if the document had a key table, do the values still sit under the right headers?
4. can you tell where an important image or figure used to be?
5. if you ask an internal teammate “which section would you chunk separately?”, do they see the same boundaries the Markdown file shows?

If the answer to those five checks is mostly yes, the pipeline is usually ready for chunking. If not, the problem is still upstream.

Common mistakes

Chunking the raw PDF extraction

If the source is still noisy, the chunker is not solving the real problem. It is just slicing the problem into smaller pieces.

Treating scanned and digital PDFs the same way

Scanned files usually need OCR before they deserve to be judged as Markdown-ready.

Optimizing for perfect visual fidelity

RAG usually benefits more from structural clarity and source traceability than from recreating the exact visual feel of the PDF page.

Forgetting the downstream task

If the destination is really a human editing workflow, Word may be a better endpoint than Markdown. If the destination is table work, Excel may be the right branch for those pages.

A realistic example

Imagine a support team migrating old product manuals into an internal assistant.

If they upload raw scanned PDFs straight into the retrieval layer, the assistant may retrieve broken sections, flattened table fragments, or weakly segmented pages. A better route is:

• OCR the scans first
• convert them into Markdown
• verify chapter headings and troubleshooting tables
• remove repeated page furniture
• then chunk by meaningful sections

That usually improves retrieval quality more than any last-minute prompt tweak.

Another realistic example

Imagine a product team with 40 PDF release notes. Half are born-digital exports from Docs. The other half are scanned partner PDFs with screenshots and embedded tables.

If they chunk all 40 files the same way, retrieval quality will swing wildly between documents and nobody will know whether the problem came from OCR, Markdown cleanup, or chunking.

A better route is:

• born-digital files go straight to Markdown review
• scanned partner PDFs go through OCR first
• tables get one focused validation pass before indexing
• release-note metadata such as version and month are added before chunking

That is the kind of small operational discipline that keeps a knowledge base from becoming “searchable, but unreliable.”

FAQ

Should I always use Markdown for RAG?

Not always, but Markdown is often the most practical structure-first format when the team needs reusable, inspectable text rather than opaque PDF extraction.

Should OCR happen before chunking?

Yes, when the relevant pages are scanned. OCR is what turns an image-based page into something chunking can use meaningfully.

What matters more, cleanup or chunk size?

Cleanup first. Chunk size only becomes useful once the document structure is already trustworthy.

Next step

If the file is scanned, start with PDF OCR . If the file only needs structural conversion, continue with PDF to Markdown . If you still need document triage before choosing a destination, use Before Converting a PDF .