Practical guide
Why Markdown is a useful checkpoint before embeddings
A RAG pipeline is only as trustworthy as the document representation it retrieves. Sending raw PDF extraction directly into a chunker can hide broken reading order, repeated headers, missing section boundaries, and detached captions. Markdown provides a reviewable intermediate layer: headings can become semantic boundaries, page comments can support source tracing, lists remain visible, and obvious extraction failures can be corrected before indexing. This makes debugging retrieval quality more concrete than inspecting anonymous chunks after embedding.
Conversion alone does not make a document retrieval-ready. After exporting Markdown, remove boilerplate that repeats on every page, preserve source metadata, define chunk boundaries around meaning rather than fixed character counts alone, and keep enough overlap for references that cross paragraphs. Store the original file name and page marker with each chunk. When an answer is generated, those fields can help your application show a source and let a reviewer return to the correct PDF page.
When to use PDF to Markdown for RAG
- You are building a searchable knowledge base from manuals, policies, reports, or papers.
- You need a readable artifact that subject-matter experts can inspect before indexing.
- Your retrieval results require page-level source references rather than a file name alone.
- You want consistent preprocessing for a mixed collection before choosing chunk size or embedding settings.
Workflow
Prepare a PDF for RAG in four stages
- 01
Convert to Markdown
Extract the PDF with page markers enabled and preserve paragraph breaks so source structure remains visible.
- 02
Normalize the document
Remove repeated headers and footers, repair obvious heading errors, keep tables or captions near their explanations, and retain source metadata.
- 03
Chunk by meaning
Use headings, paragraphs, and topic transitions as boundaries. Add overlap only where context genuinely crosses a boundary.
- 04
Evaluate retrieval
Create representative questions, inspect the retrieved chunks and page references, and revise conversion or chunking rules before scaling ingestion.
Conversion example
Example: page-aware Markdown for a retrieval chunk
This example keeps the policy heading and page marker together. A later ingestion step can attach the source file and page number as metadata without guessing where the text came from.
Source PDF content
Page 14
ACCESS REVIEW POLICY
Managers review active accounts every quarter.
Exceptions must include an owner and expiry date.Markdown output
<!-- page: 14 -->
## Access review policy
Managers review active accounts every quarter.
Exceptions must include an owner and expiry date.
Metadata: source=security-handbook.pdf, page=14Quality benchmark
RAG preparation benchmark
Evaluate the intermediate Markdown and the downstream retrieval behavior separately. A clean-looking file can still retrieve poorly, while a plain file with reliable headings and page metadata can perform well.
| Document profile | Recommended route | Pass criteria |
|---|---|---|
| Single-column policy manual | Local conversion, then semantic chunking | Representative questions retrieve the correct section and preserve the source page. |
| Research paper with footnotes and figures | Convert, clean captions, then evaluate | Abstract, methods, and findings stay separated; citations do not displace the main reading order. |
| Multi-column report or scanned appendix | OCR or manual review before indexing | No empty chunks, crossed columns, or unsupported claims enter the production collection. |
This benchmark is an acceptance matrix, not a claim that every PDF reaches the same accuracy. Test representative files from your own collection before automating a large queue.
What conversion cannot solve for a RAG system
A converter can expose structure, but retrieval quality also depends on corpus design, metadata, chunking, embeddings, ranking, prompts, and evaluation.
- Repeated headers and legal footers can dominate retrieval unless removed during normalization.
- Tables split across pages may need a custom representation or separate structured extraction.
- Page markers improve traceability but should usually be stored as metadata rather than embedded into every answer.
- Sensitive documents require an access-control model that is enforced during retrieval, not only during upload.
Frequently asked questions
PDF to Markdown for RAG questions
1Is Markdown always better than raw PDF text for RAG?
Not automatically. Its value is visibility and structure: people can inspect headings, page markers, lists, and failures before indexing. A raw extractor may be sufficient for simple files, but Markdown is often easier to normalize and version.
2Should page markers be included in every chunk?
Preserve them during conversion, then attach the relevant page number as chunk metadata. This supports citations without forcing page comments into the prose sent to the model.
3How large should RAG chunks be after PDF conversion?
There is no universal size. Start with semantic boundaries such as sections and paragraphs, then evaluate retrieval using real questions. Adjust size and overlap according to document style and answer granularity.
4Can scanned PDFs be added to a RAG knowledge base?
Yes, but run OCR and manual quality checks first. Empty pages, character errors, or broken reading order can become confident but unsupported answers after indexing, so scans need a stricter acceptance gate.